EM Ref. Ares(2020)8010737 - 31/12/2020 


SDN-uSense 


Project No. 833955 
Project acronym: SDN-microSENSE 


Project title: 


SDN - microgrid reSilient Electrical eNergy SystEm 


Deliverable D4.5 


Blockchain-based Energy Trading Framework 


Programme: H2020-SU-DS-2018 
Start date of project: 01.05.2019 
Duration: 36 months 


Editor: CERTH 


Due date of deliverable: 31/12/2020 Actual submission date: 30/12/2020 


This project has received funding from the European Union's Horizon 2020 
research and innovation programme under grant agreement No 833955 


(x) SDN-uSense 


D4.5 
Version 1.0 


Deliverable Description: 


Deliverable Name Blockchain-based Energy Trading Framework 
Deliverable Number D4.5 
Work Package WP 4 
Associated Task T4-5 
Covered Period MO5-M20 
Due Date M20 
Completion Date M20 
Submission Date 23/12/2020 
Deliverable Lead Partner CERTH 
Deliverable Author(s) CERTH, TECNALIA, IREC, IDENER, IPTO 
Version 1.0 
Dissemination Level 

PU Public X 
PP Restricted to other programme participants (including the Commission 

Services) 
RE Restricted to a group specified by the consortium (including the 

Commission Services) 
CO Confidential, only for members of the consortium (including the 

Commission Services) 


CHANGE CONTROL 


DOCUMENT HISTORY 


13/11/2020 | Table of Contents 


20/11/2020 


30/11/2020 


05/12/2020 


State of the art in blockchain- 
based energy trading systems 
completed 


Requirements analysis section 
completed 


All sections related to 
Blockchain-based Intrusion 
and Anomaly Detection 
module completed 


© SDN microSENSE consortium 
Public document 


Change History | Author(s) — | Organisation | 


Vakakis Nikolaos, 
Pasias Achilleas, 
Kotsiopoulos 
Athanasios 
(CERTH) 

Jose Antonio Perez 
Jimenez (IDENER), 
Panagiotis Famelis 
(IPTO) 

Vakakis Nikolaos, 
Lazaridis Georgios 
(CERTH), 

Marisa Escalante 
Martinez, Inaki 
Seco Aguirre, 
Dediego Santiago 
(TECNALIA) 


CERTH 
IDENER, IPTO 


CERTH, TECNALIA 


TECNALIA 


Page | 2 


Marisa Escalante 
Martinez, Inaki 
Seco Aguirre, 


(x) SDN-uSense 
D4.5 


Version 1.0 
Dediego Santiago 
(TECNALIA) 


Vakakis Nikolaos, 
Development section of e- Kotsiopoulos 
na 12182020 auction module completed Athanasios 
(CERTH) 


Vakakis Nikolaos, 
Kotsiopoulos 
Athanasios, 
Lazaridis Georgios, 
Pasias Achilleas 
(CERTH), 
Marisa Escalante 
. | Martinez, Inaki CERTH, TECNALIA, 
14/12/2020 | First draft for peer review Seco ADUNE, IPTO, IREC 
Dediego Santiago 
(TECNALIA), 
Jose Antonio Perez 
Jimenez (IDENER), 
Panagiotis Famelis 
(IPTO), Pol Paradel 
Sola (IREC) 


Vakakis Nikolaos 
(CERTH), Marisa 
Second peer review version, Escalante Martinez 
0.7 23/12/2020 | addressing the comments (TECNALIA), CERTA, 
dn f S .. | IPTO, IREC 
from initial peer review Panagiotis Famelis 
(IPTO), Pol Paradel 


Sola (IREC) 


Final version, after receiving Vakakis Nikolaos 
1.0 29/12/2020 | and addressing the reviewer's (CERTH) 


comments 


DISTRIBUTION LIST 


Date [issue Groups 
16/12/2020 Energynautics, SINTEF, TM, QM, SAB 
23/12/2020 2"d Revision Energynautics, SINTEF, TM, QM, SAB 
24/12/2020 


29/12/2020 SINTEF, TM, QM 
30/12/2020 
30/12/2020 AYESA 


© SDN microSENSE consortium Page | 3 
Public document 


(x) SDN-uSense 


D4.5 
Version 1.0 
SAB APPROVAL 
NAME INSTITUTION DATE 
Prof. Sokratis Katsikas NTNU 30/12/2020 
Marc Stauch LUH 30/12/2020 
Dave Raggett ERCIM 30/12/2020 
Academic and Industrial partner revision 
NAME INSTITUTION DATE 
Ellen Krohn Aasgärd Academic partner: SINTEF 29/12/2020 
Nis Martensen Industrial partner: 21/12/2020 
Energynautics 
Quality and Technical manager revision 
NAME INSTITUTION DATE 
Dimosthenis loannidis CERTH 27/12/2020 
Drosou Anastasios CERTH 27/12/2020 
© SDN microSENSE consortium Page | 4 


Public document 


(x) SDN-uSense 
D4.5 


Version 1.0 


Table of contents 


Table Of CONTENTS amandes REDEE NEE Fax FERNER AV abonnant teint ai 5 
ACIONY NS —————————————————MÓ 7 
List OF FIQUIES OR —————— MÀ 8 
List OF pool WE ————————————— 9 
Executive SUmPmabyausienensavkekid ku REVRRAE WERTE KE EVEN FERE a italiennes RUE RIF nda ida da PRU 11 
1; IMPOR Mr E—À————————————— 12 
1.1 Púrpose-of this docürnent;... uice iot rt o ee Ee re d En EE eas ua gen Les D Fat over eurn 12 
1.2 Relation to other tasks and deliverables .........................eseeeeeeeenenneen nnne 12 
1.3 Structure of this :COCUIMENE see iore e entente etes NN de Ines en EF eren conteste oe Ere Stee 12 

2. State of the art in blockchain-based energy trading systems ..................................... 13 
3. Architecture and Requirements eere rotate aere skusa epe kaes dona REF V raa PARU ED NT sau sis s RM EE ER PARES 16 
3.1 Objective of the system and placement in SDN-microSENSE architecture ........................... 16 
3.2 Reqüiremierits-analysls:::.:::::: 1 i cerv c ste En ERE RR ca ESG AU AVES RR EXER TE ESA TENER USER AR QR eevee 17 
3.2.1 Major inputs and outputs nn nennen nnne nnns esent 17 
3.2.2 Functional requirements ............... iii 18 
3.2.3 Non-functional requirements iii 20 

4. System andlysiS mE ————————— 23 
4.1 Component Modelirne tote rte iet viste aE EENE E es 25 
4.1.1 E-aüction module... nte EH OR HE a aS 25 
41.111 .E-aüctior miechahlstT: uice rr tenente D RE eevee Co andas ieu ee ean 26 
4,01.2. Penalty mechanism coii etit ordered ined uen en eoe een P enean utere bu ka ttes 30 
4.1.1.3  Vickrey-Clarke-Groves chaincode ..........cccccesssssececeessesnaeeeceescessaeaececesssesaeaeseeeesseseaaeas 33 
4.1.1.4  ERC20 token chaincode..…....................... siennes 38 
4.1.1.5 Priority table chaincode ins 40 
4.1.1.0. Market chairicode iue maniement 42 
4.1.1.7 Eauction Module APIs... itte tre Pe eX een gana Td aaa 43 

4.1.2 Blockchain Based Intrusion and Anomaly Detection module........................................ 57 

4.2 Interfacesmodel ssa. sims tied tete Rhinite tin dan aqu ra 62 
4.2.1 External interfaces with other SDN-microSENSE application plane modules ............... 62 
4.2.1.1 Communication of e-auction module with EMO ...................... eene 62 

4.2.1.2 Communication of e-auction module with S-RAF........................ 64 

© SDN microSENSE consortium Page | 5 


Public document 


(x) SDN-uSense 
D4.5 


Version 1.0 


4.2.1.3 Communication of Blockchain-based Intrusion and Anomaly Detection with XL-SIEM 


64 
4.2.2 External interfaces with SDN-microSENSE infrastructure plane modules..................... 65 
4.2.2.1 Connection of e-auction module with RPI of smart meter..…......... 65 


4.2.2.2 Connection of Blockchain Based Intrusion and Anomaly Detection module with RPI 


Of smart Metel 32 sit rn hrs in ———————Á—— 67 

5; System VERIA TIO er ———————— HH 68 
5.1 E-auction module unit tests... sise 69 
5.2 Blockchain Based Intrusion and Anomaly Detection module unit tests.............................. 116 

6: System INSTHNOHON RR —————————————— sia atas 131 
6.1 E-auction module: 3. sro ee O tart At e es ul tenter dee Puce intense Penns 131 
6.1.1 E-auction module installation... 131 

6.2 Blockchain Based Intrusion and Anomaly Detection module.............................. esses 132 
6.2.1 BIAD installation: irrito re ect sem e Er EE ea hee Rs oou gas 132 
6.2.2 Iri m 133 

7. Innovation SummoüFy...:...2 oes eoe rep ee ve vus ny va | yap o Sas Gv aU so P be Fica eura o aoo luas eoe eaae Ire pe Rep o Ea ous 133 
Bi. CONCIUSIONS mer ——————————— 135 
REPONENCOS io acies ec edo E T E RU essai M ciui caen Cv du REI MGE E UAMAM inde 137 
© SDN microSENSE consortium Page | 6 


Public document 


(x) SDN-uSense 


D4.5 
Version 1.0 
Acronyms 
Acronym Explanation 
AA Adaptive Aggressiveness 
API Application Programming Interface 
BIAD Blockchain-based Intrusion and Anomaly Detection 
CDA Continuous Double Auction 
DER Distributed Energy Resource 
DLT Distributed Ledger Technologies 
DSO Distribution System Operator 
DHT Distributed Hash Table 
EC Energy Contribution 
EPES Electrical Power Energy System 
ESCO Energy Service Company 
ESS Energy Storage System 
EV Electric Vehicle 
GUID Globally Unique Identifier 
ISO Independent System Operator 
IDPS Intrusion Detection and Prevention System 
LCOE Levelized Cost of Energy 
LV Low Voltage 
MSP Membership Service Provider 
P2P Peer to Peer 
PV Photovoltaic 
QoS Quality of Service 
SDK Software Development Kit 
SPoF Single Point of Failure 
TLS Transport Layer Security 
TRL Technology Readiness Level 
TSO Transmission System Operator 
UUID Universally Unique Identifier 
ZIP Zero Intelligence Plus 
© SDN microSENSE consortium Page | 7 


Public document 


(x) SDN-uSense 
D4.5 


Version 1.0 


List of Figures 
Figure 1: Placement of blockchain-based energy trading system within SDN-microSENSE architecture 


E —————————————— E ANDO RR 17 
Figure 2: e-auction Fabric network architecture ............cccssssccceeessesseeceeecessesesaeececesseseseeeeeesseeseseaeeeseeses 26 
Figure 3: VCG auction mechanism demonstration with 3 winners .............ccsscccecesesssseceeeeesessesteaeeeseesees 27 
Figure 4: VCG auction mechanism demonstration with 1 winner. ss 27 
Figure 5: VCG auction mechanism demonstration, winners defined by priority of bidding................. 28 
Figure 6: Auctioneer-Bidder API endpoints iii 44 
Figure 7: /apply request parameters and responses .…......................................... enne nnne 45 
Figure 8: /getBalance request parameters and responses... 46 
Figure 9: /transfer request parameters and responses... 47 
Figure 10: /initVickreyCGAuction request parameters and responses ..........cccseceesecesseeesseceescecesseeeseeees 48 
Figure 11: /getVickreyCGAuction request parameters and responses ..........cccsccesseecsseeeseceessecesseeeeeees 48 
Figure 12: /VCGsubmitSealedBid request parameters and responses... 49 
Figure 13: /VCGreveal request parameters and responses... 50 
Figure 14: /VCGaward parameters and responses... 50 
Figure 15: /VCGsettle request parameters and responses... 51 
Figure 16: /getMarkets request responses... 51 
Figure 17: /applyToMarket request parameters and responses... 52 
Figure 18: /getPriorityTable request responses .…................................................ 52 
Figure 19: ESCO API endpoints: eiie be e ER Eae VETE TEE bet REPE egestas 53 
Figure 20: /initToken request parameters and responses .........ccscccssscesssceccecescecesseccsaecesaeeeessecsaeecesneees 54 
Figure 21: /getApplicants request parameters and responses... 55 
Figure 22: /updateBalance request parameters and responses... 56 
Figure 23: /initMarket request responses iii 57 
Figure 24: /initPriorityTable request responses ............seessseseeeeeneenenen enne 57 
Figure 25. Blockchain Based Intrusion and Anomaly Detection system components .......................... 59 
Figure 26: BIAD behaviour model... inserer 62 
Figure 27 Example request of Market Validator ...................... esses ss 63 
Figure 24: Agent algorithm nce oett ta deste do req s NN tete tie etes diet 66 
Figure 25: Penalty paying algorithm iii 67 
© SDN microSENSE consortium Page | 8 


Public document 


(x) SDN-uSense 
D4.5 


Version 1.0 


List of Tables 


Table 1: List of functional requirements covered by the Blockchain-based Energy Trading System... 18 
Table 2: List of non-functional requirements covered by the Blockchain-based Energy Trading System 


RP Coden AA A TE E E RP E PR RE PP ERON 190 A RN RR 20 
Table 3: Permissioned vs permissionless blockchain networks... 23 
Table 4: Comparative analysis of different blockchain platforms .............cccccssccecesessssecceeeesessesseaeeeseesees 23 
Table 5: Sample priority table... ire 30 
Table 6: Sample priority table with prosumer 1 being imposed 50 tokens of penalty ......................... 31 
Table 7: Sample priority table with prosumer 1 being imposed 50 tokens of penalty and prosumer 4 
being imposed 100 tokens of penalty... iii 31 
Table 8: Sample priority table with prosumer 1 having paid 50 tokens of penalty and prosumer 4 
being imposed 100 tokens of penalty... 31 
Table 9: Vickrey-Clarke-Groves chaincode functions ...................sssssseseee eene 33 
Table 10: Vickrey Clarke-Groves auction structure Us 34 
Table:11: Participant structUre.:5.2 cpm Decet t ie reci ee Ce re rer e EE a RE pt ev ET een Re EE aiie 36 
Table 12: Commodity structure ...........cccesscccecesssssseececeseesesaeaeececeeeesaeeceescessuseeaeseseuseeseaaeaecesseeseasaeeeseesees 36 
Table 13: Result StEUCEUre ss irit re tre scene eco re eed tape SE nee dan rid ed pd Ea sans eae ERA o adaga dead UNA É A 36 
Table-14:* Hidden Bid ‘Structure sacs i oro reet dra dia dues dco eed cee tues Dida aa tira dee ett dee ee uere ie ege ira 37 
Table 15: RevealedBid'StrüctUre.......... heat renier ie tnt Reagan ul 37 
Table 16: ERC20 token chaincode functions... sise 38 
Table 17: Token:strÚCtuUre: I ————————————————————Á———————————— RR 40 
Table 18: Priority table chaincode functions ................... essit nn nnne 40 
Table-19: Priority Table:structune s. «LR eese red e i e e TREE eb ERE 41 
Table 20: Market chaincode functions iii ener eene enne nnns 42 
Table 21: Market.strüctUFe. iicet teretes teo tried on edo oa et ta ed eR ARAL ET de tx Ud ad Udo a EE neon da ed ea dt ado 43 
Table 22 Functions from the chaincode................... siens 59 
Table 23 Device strüctUre..:: esce re eret ente de sides Jeeta redo os hee o aka ene ERR Ada NET MS MERE EUM E ARE TEUER UE TEUER ETUR E dde 60 
Mable 24: Hash Structures, eicere n nre ree rio P aede e e niet isa dla nec a Uu e dé eerie 60 
Table:25.Record Structure 28m dr an dee Co C du EE etr a ER ER ds iude ka v ie tele 61 
Table 26 Alert Structure us cerent atirar rete AE n ede GT aU Tala ganda ua ag aa 61 
Table 27: EMO = e-auction interface... eoe ane anat derecha dete cba det eroe aderat ds 62 
Table 28: e-auction — SRAF interface ..........cccccccessstecesseeecesseeeeesceneecessesececeeesecsseueeceseeesessceaaeesseeeeeeseeaaees 64 
Table 29: BIAD - XL-SIEM interface ...............esssssssesseseeeeeee eene enhn enne sse nnns enne seen ennt 65 
Table 30: E-AUCTION. OT Unit test... nitet ettet tese det ditado sit enero taa ide ka ode EL a EE De ERR ede dea ed d ART dde 69 
Table 31: E-AUCTION:-02 Unit test... iier eres ether npn tos reg ck e CR dado a Ex ada cR eere eds ça dicas 82 
Table 32: E-AUCTION_O4 unit test... oie sere eaa etie es tere ea te cana ascende de vea dete eR Ue ana deese esee agde 93 
Table 33: E-AUCTION O5 unit test... eene enne nnne nnns sn etn nennen n raastaa neria renns oa 111 
Table 34: BIAD 01 unit test sincsen e ekea aaa aaa Ea rE rA Eaei 116 
Table 35: BIAD -02 Unit test... serre totu teet E as gant ade ratas gm ta gu qt asas tod Rees 118 
Table: 36º BIAD-03 UNIT test... aie terere tatc ice Ratio net Evo T E ER Rr uod 122 
Table 37:BIAD--04 ünit test... eroe ei t ae ia ceased ease Herren tin ue ols e aie erue e Ue de RYE HUN 125 
Table 38: Lib mon 001 unit test .0.... ccc cecsssesssecececessesesaeeeeeseesseeeaeeeeecesseseuaeeecesseesesaaeeeesessseeeaeeeeess 129 
Table 39: Lib hash. 001 Unit test... ert eren anre ven eon ey ree ba RR EEEN ETENE 129 
Table 40: Fabric conn 001 unit test inner 130 
© SDN microSENSE consortium Page | 9 


Public document 


(x) SDN-uSense 
D4.5 


Version 1.0 


Table:41: agent: 001 Unit test. o ote eerte mut oia ua ie Un eie Udo Ud dors AAE e antenne 


© SDN microSENSE consortium Page | 10 


Public document 


(x) SDN-uSense 
D4.5 


Version 1.0 


Executive Summary 


This document is a deliverable of the SDN-microSENSE project, funded by the European Commission 
(EC) under its Horizon 2020 Research and Innovation Programme (H2020). 


It comprises deliverable D4.5, Energy Exchange using Blockchain Technologies of the SDN-microSENSE 
project. The developed Blockchain-based Energy Trading Framework is a module of the SDN-SELF 
component, that utilizes Fabric blockchain technology to achieve secure and sustainable energy 
transactions between the participants of a permissioned blockchain network. The two modules of the 
Energy Trading Framework are the e-auction and the blockchain-based Intrusion Detection System. 
The task receives as input the Functional Use Case Requirements, the Data Protection Requirements, 
the Data Security Requirements and the Reliability Requirements from task T2.2, as well as the SDN- 
microSENSE platform specification and architecture from T2.3. The output it produces is the fourth 
layer of the SDN-SELF component. The document includes the identification of the aforementioned 
requirements and the analysis of how they are being addressed, as well as a State-of-the-Art Analysis 
of recent literature, related to the Blockchain technologies and the energy markets. Subsequently, 
based on these assessments, the Blockchain-based Energy Trading Framework is thoroughly described, 
including the functionalities, the inputs/outputs and the interconnections with other SDN-microSENSE 
components and modules. 


The framework is based on a permissioned blockchain network, which ensures that energy and 
financial transaction-related data are not exposed outside the consortium of organizations 
participating in the network, while it allows them to interact with smart contracts (chaincodes) to 
perform several actions within the network. The privacy of the participants is achieved by utilizing 
communication channels between organizations which ensure exposure of transactions and related 
data only to authorized members of those channels and not to any other network members. 
Furthermore, the nature of the blockchain technology ensures trusted transactions between the 
participants and non-repudiation of actions. Additionally, the Energy Trading Framework, receives and 
utilizes input from SDN-microSENSE security, risk assessment and decision support layers, thus 
ensuring safety of transactions against cyber-security threats and destabilization of the grid. 


The Technology Readiness Level (TRL) of the Energy Trading Framework by the end of the project is 
expected to be equal to 7, since it will be evaluated in real life operational environment, consisting of 
a group of prosumers belonging to same DSO, in Use Case 6. 
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1. Introduction 


1.1 Purpose of this document 

The purpose of this document is to present the research conducted and the results achieved in Task 
4.5, Energy Exchange using Blockchain Technologies. The task is included in Work Package 4, Cyber- 
secured & Resilient SDN-based Energy Ecosystem. The blockchain-based energy trading system is a 
module of the SDN-SELF component which utilizes blockchain technology to host an energy exchange 
framework, the operation of which takes into account the energy sustainability, the privacy of the 
participants sensitive data, and the security of their infrastructure. 


1.2 Relation to other tasks and deliverables 

Task 4.5 receives the security and privacy requirements from task 2.2 and the platform’s architecture 
from task 2.3 and produces the fourth layer of the SDN-SELF component. Deliverable 4.5 interacts with 
the following deliverables, references to which will be found in this document: 


e D2.2, User & Stakeholder, Security and Privacy Requirements: This deliverable is the output 
of Task 2.2 and defines the user (energy operators, prosumers, consumers etc.), the security 
and the privacy requirements of the SDN-microSENSE project. 

e D2.3, Platform Specification & Architecture: This deliverable is the output of Task 2.3, which 
defines the SDN-microSENSE architecture fed by the energy application requirements in 
security, privacy, and information protection. 

e D3.5, Implementation of SDN-microSENSE Risk Assessment Framework: This deliverable is 
the output of Task 3.5 and assesses the level of risk in all the involved EPES devices and 
systems and forwards the data to the Energy Trading Framework. 

e D4.4, Distribution Grid Restoration using Deterministic Optimisation and Machine Learning- 
based Threat Handling: This deliverable is the output of Task 4.4 and deploys the appropriate 
management processes that will balance the energy supply and demand for each island. 
These processes will determine whether the transactions conducted in the Energy Trading 
Framework endanger the island's stability or not. 

e  D5.1, Large Scale SIEM & Ultrafast Logging: This deliverable performs effective and timely 
logging of cybersecurity events in the EPES and provides advanced protection for the 
involved stakeholders of the Energy Trading Framework. 


1.3 Structure of this document 
The document is structured in 8 sections as follows: 


1. Section 1 is the introduction of the document, and it presents the structure of the document, 
the purpose of the deliverable, and its relation to other tasks and deliverables. 

2. Section 2 includes the State-of-the-Art Analysis of recent literature, related to Blockchain- 
based trading systems. 

3. Section 3 identifies the user, security and privacy requirements and describes how they are 
addressed by the Energy Trading Framework. Also, it describes the placement of the Energy 
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Trading Framework within the SDN-microSENSE architecture and documents its major inputs 
and outputs. 

4. Section 4 analyses the functionalities and the interfaces of the two modules of the 
framework, namely the e-auction module and the Blockchain-based Intrusion and Anomaly 
Detection (BIAD) module. 

5. Section 5 demonstrates the unit tests that were conducted in order to ensure that the two 
modules’ operation is sustainable and efficient and presents their results. 

6. Section 6 describes the procedures and the specifications required for the installation of the 
e-auction module and the BIAD Module. 

7. Section 7 presents the innovation summary that this deliverable proposes. 

8. Section 8 concludes the document. 


2. State of the art in blockchain-based energy trading systems 


The latest technological developments are leading us to the transition to decentralised power systems. 
Microgrids, distributed energy resources (DERs) and micro-generation are transforming traditional 
consumers to what is called prosumers, i.e., consumers who also produce energy, thus enabling them 
to participate in the energy grid in new disruptive ways. This new approach introduces new challenges 
and opportunities in the energy markets. Until now, the energy market access was centralised, usually 
orchestrated by the System Operator (an ISO or a TSO) and concerned large generation units and 
clusters of units controlled by bigger parties and corporations making it difficult for small scale 
prosumers to actually participate in the energy market. By developing decentralized markets and 
enabling prosumers to trade among themselves and on the edge of the grid, a more robust and cleaner 
system can exist. In the technical and academic literature, new decentralised approaches have been 
developed to tackle this challenge. 


One of the most recurring technique is the use of blockchain-based energy trading systems. On this 
aspect, distributed ledger technologies (DLT) such as blockchain technologies enable the decentralised, 
trusted, and secure exchange of energy trading transactions between parties. The blockchain systems' 
decentralised nature enhances system resilience to outages and cyberattacks, avoiding the single point 
of failure design of many current centralised systems. Additionally, the data in blockchain systems is 
easily verifiable by interested parties and always available, enhancing data integrity and accounting. 
All of these features, along with the automation provided by the introduction of smart contracts in the 
blockchain machinery, establishes this technology as a basis for the future energy sector [1]. On the 
context of Task 4.5 of this project, several technical implementations have been carried on new 
blockchain-based energy trading technologies and tools. On this aspect, the current state of the art in 
this field is presented in the upcoming paragraphs. 


In 2017, Wang et al. [2] proposed a peer-to-peer decentralised electricity transaction mode for 
microgrids based on Bitcoin [3] as a blockchain and currency system and the use of the continuous 
double auction (CDA) mechanism. Additionally, this work applies an adaptative aggressiveness (AA) 
trading strategy for increasing profits to market participants. The CDA mechanism is a fixed-duration 
auction system in which several buyers and sellers bid on the market to buy and sell goods (in this case, 
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energy), respectively, and where transactions will take place at any time if an offer to buy and an offer 
to sell match [4]. Based on this transaction pattern, prosumers will send quotes to the CDA market 
according to an AA strategy throughout this transaction pattern and adjust quotes continuously 
according to transaction results. Buyers and sellers achieve digital proof of energy transaction and 
settlement of contracts using blockchain once the market matches, thereby achieving direct microgrid 
electricity transactions. Bitcoin is used for currency exchange, and digital certificates are employed as 
contracts that indicate the right to use the corresponding electricity once the auction ends. 


Later, A. Hahn [5] et al. demonstrated the use of blockchain-based energy auctions through the 
Ethereum blockchain technology [6]. The auction mechanisms implemented through smart contract is 
the Vickrey second price auction [7] mechanism to encourage honest bids on auctions. This work had 
a real successful implementation on a testbed with a 72kW photovoltaic (PV) array. The architecture 
of this work is based on multiple agents in charge of selling and bidding operations, including smart 
meter agents and the respective agent for smart contract execution. 


In 2018, Guerrero et al. [8] introduced the first technique for ensuring network constraints in P2P 
blockchain-based trading schemes in low-voltage (LV) networks. This work is based on a CDA auction 
mechanism with a zero intelligence plus (ZIP) strategy implemented as agents. ZIP agents use an 
adaptive process that can offer output somewhat close to that of stock exchange traders. The last key 
aspect of this work is the Network Permission Structure. This mechanism validates the auctions' 
voltage variations and line congestions to prevent problems in the network while informing the market 
participants of potential issues. Moreover, the transaction system internalises the extra cost due to 
the technical constraints of the network. The benchmarks carried on this work indicate that this 
scheme does not suffer from scalability issues which is a recurring issue of blockchain-based 
environments. 


Furthermore, a new blockchain-based energy trading scheme is presented in [9]. In this work, Li et al. 
introduce a new variant with permissioned blockchain technologies to protect privacy and security. 
This way, having a more restricted blockchain instead of a public one, the attack surface is reduced 
while preserving privacy to specifically authorised participants in the market. Another interesting 
addition to preventing the delay in blockchain-based transactions is the introduction of a credit-based 
payment scheme to support faster and more frequent trading among peers. The removal of the use of 
cryptocurrency results into an enhancing of performance of the overall energy trading scheme. 


Privacy is also the subject of the work in [10]. As Gai et al. discuss one of the main disadvantages of a 
blockchain solution is its vulnerability in terms of linking attacks. As the transactions are traceable, an 
attacker that has access to other public data (from utility companies or from public records for 
example) could link transactions to users even if they are anonymised. They describe three types of 
attacks and present a way of defend against them. The basic idea revolves around the mapping of 
different accounts. Basically, every time transactions exceed a certain threshold, the payments are 
deposited to newly created accounts, which are mapped to the original, making it difficult for the 
attacker to discover the mappings. The proposal takes into account also the fact that some accounts 
may be inactive for some time; to preserve their privacy, the system creates new dummy accounts 
every time a new account is created, proportional to the inactive accounts, every time a transaction is 
made. 
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An interesting combination of machine learning and blockchain can be found in [11]. Ferrag et al. 
propose the Deepcoin framework that uses a byzantine fault tolerance based blockchain together with 
a deep-learning IDS to detect network attacks and deceitful transactions. They describe a blockchain 
architecture encompassing home, building and neighborhood networks where prosumers can trade 
energy amongst themselves. On top of that, they develop a deep learning algorithm that checks if the 
offers, from sellers or buyers, are genuine, trusted and comply with the set of rules of the system. They 
also evaluate the Deepcoin framework with different sets, providing accuracy over 9096 against most 
types of attacks. 


Wang et al. in [12], propose a trading system that is able to integrate with today's operational models 
based on crowdsourcing. They categorize between two different classes of energy trading transaction, 
between prosumers or crowdsourcees and the utility, as they exist today and among crowdsourcees. 
The algorithm minimizes costs by rescheduling any shapeable loads and DERS. In the first phase it 
behaves akin to day-ahead scheduling, which is the form most markets work today. However, in the 
second phase any balances that need to be made are first discovered in the local trading market. They 
also propose different pricing schemes for each type of transactions, on the one hand providing 
incentives to prosumers to participate in the balancing market and allowing to negotiate prices among 
themselves. Their proposal in most cases require a central authority to manage the grid and clear the 
market, however island use cases are described where small-scale energy trading exists without any 
central authority. 


Of course, the blockchain P2P markets are not without problems. Hoarding of energy can be observed, 
with prosumers buying energy when it is cheaper and keeping it to influence the market prices. This is 
the problem [13] tries to tackle by providing a demurrage mechanism. Yashaya et al. describe a market 
model where they try to optimize consumption by shifting demand to off-peak hours and incentivize 
nearby prosumers to buy on DERs' peak hours. This is done by changing the price of energy with time, 
so when a prosumers hoards energy or delays to buy time, the buying price will be higher and the 
selling price lower than the utility's price. Therefore, for a prosumer to increase selling price, they 
should increase their consumption and to decrease the buying price, they should decrease their 
consumption. To implement this they use smart contracts, not just as algorithm for the trading itself 
but trying to incorporate in them any contractual clauses, regulatory guidelines etc. According to their 
results the demurrage mechanism proves useful as the system produces better prices overall and 
optimizes consumption when prosumers are active in the local energy market. 


The use of smart contracts in blockchain energy trading frameworks is examined also in [14]. Han et 
al. propose a multidimensional blockchain framework, fully describing the whole process by presenting 
three layers (infrastructure, players, processes) and what each encompasses. The trading itself follows 
a double auction where the producers' bids are sorted in increasing order and the consumers' in 
decreasing order. After matching the bids, the price is beneficial for all and closer to what the 
participants would actually require. Any unmatched bids are sold or bought by the DSO, who is also 
responsible to balance and correct any imbalances. Their simulations have shown that over 8096 of the 
energy is traded locally in prices that are satisfactory and that the imbalances concern only 2,9196 of 
the total actual energy. 


Lastly, there have been some attempts to combine SDN technologies with blockchain markets as can 
be seen in [15]. Chaudhary et al. concern themselves with an EV (electric vehicles) energy trading and 
use SDN to improve QoS. Their approach touches the subject of edge networking, by describing a 
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layered architecture that separates edge and core networks, using SDN to efficiently orchestrate the 
traffic. Each area, called cloud, comprises a local SDN controller, a transaction server that maintains 
the transaction records and meets the energy demands of the users, and local aggregators that behave 
like miner nodes. Additionally, there exists a global controller, which creates the replication 
mechanism, maintains the global consistency of the database and reduces communication overhead. 
Their performance analysis shows that the proposal is lightweight and any additional overhead from 
SDN and computations is kept to a minimum. 


Also in [16], an SDN-based energy internet is proposed with attention to privacy. Lu et al. propose an 
architecture that is based on DHT, to obfuscate the users’ privacy through hash indexing, utilizing a 
bloom filter to screen the electrical energy information. The sellers produce energy and store it in the 
main energy storage systems and buyers send requests for energy with specific constraints including 
benefit, cost etc. The system is responsible to match requests to sellers and inform buyers about their 
options. Because of the use of DHT, the system behaves essentially as a black box preserving the 
privacy throughout the transaction. SDN in this case, is used more as a design framework for 
structuring energy internet in a way that separates data/energy, and forward/transaction planes and 
less as a technology itself, as the proposal is on a prototype abstract level. 


3. Architecture and Requirements 


3.1 Objective of the system and placement in SDN-microSENSE architecture 

The Blockchain-based Energy Trading System is the last layer of SDN-SELF and aims to provide a safe 
and trustworthy environment for secure energy trading within islanded parts of the smart-grid. A 
permissioned blockchain network is established between smart-grid organizations of the island, where 
they are able to take part in e-auctions as buyers or sellers or, in case of energy service company 
organizations (ESCO), manage the financial transactions through network dedicated tokens. The 
tokens are based on ERC20 protocol, which defines a set of rules regarding the manner in which the 
tokens can be transferred, how transactions are approved and how users can access data about a 
token. The Blockchain-based Energy Trading System, not only offers important features such as 
verifiability and immutability of transactions, but also leverages important information provided by 
other SDN-microSENSE application layer components and modules. More specifically, e-auction results 
are evaluated by the OTSC tool of EMO module, in order to avoid grid destabilization problems that 
may occur as a result of energy exchange agreements. Furthermore, the Blockchain-based Intrusion 
and Anomaly Detection module monitors the smart metering equipment of the organizations and 
produces security-related alerts that are sent to XL-SIEM of XL-EPDS component and subsequently to 
S-RAF component. The latter assesses the produced alerts and provides that information to the e- 
auction module, in order to deny participation to the market to organizations that may operate 
compromised equipment. The placement of the Blockchain-based Energy Trading System within the 
SDN-microSENSE platform architecture can be observed in Figure 1. 
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Figure 1: Placement of blockchain-based energy trading system within SDN-microSENSE architecture 


3.2 Requirements analysis 
3.2.1 Major inputs and outputs 


The Blockchain-based Energy Trading System receives input from the data/infrastructure plane and 
acts according to information collected from different sources of the SDN-microSENSE platform 


security and decision support layers. More specifically: 


e Receives data related to e-auction processes from sellers/buyers of energy that participate in 
the network. The e-auction module implements a specific e-auction protocol that will be 
discussed later in the deliverable. In order to initialize an e-auction or take part in an existing 
e-auction, participants have to use the API provided by the e-auction module of the 


Blockchain-based Energy Trading System. 


e Receives data related to token management from ESCO, such as token initialization and 


account initialization data. 


e Receives log, configuration and firmware files from RPIs connected to smart meters of the 
prosumers participating in the market, in order to detect possible alterations that could 


indicate compromise of the devices. 


e Sends smart meter security alerts that are detected from the Blockchain-based Intrusion and 


Anomaly Detection module to XL-SIEM module of XL-EPDS. 


e Receives risk assessment evaluation of the detected security alerts from the risk assessment 


module of S-RAF. 
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e Sends the list of energy transactions that derive from the e-auction results to the OTSC tool 
of EMO module, which is also part of the SDN-SELF component and receives evaluation of 
energy trading transactions between prosumers. 

e Emits e-auction results to be accessible to all the market participants. 


3.2.2 Functional requirements 

In Table 1, there is a list with all the functional requirements that are covered by the Blockchain-based 
Energy Trading System. Those requirements are gathered from D2.2, User & Stakeholder, Security and 
Privacy Requirements. 


Table 1: List of functional requirements covered by the Blockchain-based Energy Trading System 


FR-UR-06 The system shall be able to detect and mitigate unauthorised access in near real time (in 
seconds) and with high accuracy. 


Involved modules: BIAD, XL-SIEM 

The intrusion detection module is able to detect any change to configuration or logs files related with the 

smart meters that are recorded in the blockchain agent. This system generates an alarm that should be 

analysed by the XL-SIEM. 

FR-UR-17 The system shall be able to inform in near real time (in seconds) via email and push 

notification the Security Administrator concerning possible security incidents. 

Involved modules: BIAD, XL-SIEM 

The intrusion detection model, as soon as an access to the configuration or logs files or a failure in the 

connectivity test is detected, generates an alarm that should be analysed by the XL-SIEM. 

FR-GR-06 The system shall be able to monitor in real time relevant physical parameters at all points of 

interest in the grid infrastructure. 

Involved modules: BIAD 

The intrusion detection component is available to detect information regarding the usage of RAM and send 

an alert if this usage is under the threshold established. Also, allows to detect if the smart meter is connected 

and in case of detecting that it is not connected, generates an alert. 

FR-UC4-01 The system shall perform through encrypted contract (e.g. by using blockchain or similar 

technology) and protect the privacy of the energy trading parties 

Involved modules: e-auction 

The communication between the participants of the e-auction module is performed through a private Fabric 

blockchain network. Each participant in the network owns a digital certificate which identifies her/him as a 

member of the network. In the context of the market, participants are identified by the unique composition 

of two factors: the Membership Service Provider ID and the Certificate ID (public key) and no other 
information is exposed. Furthermore, the deployment of the sealed bid Vickrey-Clarke-Groves auction 
mechanism within the energy trading system, ensures that the bids are cryptographically protected and not 
revealed to other participants until the bidding deadline. After revealing the bids and performing the 

Vickrey-Clarke-Groves auction algorithm to award the winners, the results are exposed only to the channel 

for which members the e-auction is conducted and not to any other network members. 

FR-UC4-02 e Thesystem shall provide a specific auctions-oriented protocol to allow an energy 
trading e-auction (an electronic auction for energy trading between EPES 
stakeholders) between EPES ecosystem’s stakeholders. 

e The system's energy trading framework shall support cryptographic mechanisms to 
ensure non-repudiation of bids during an e-auction. 

Involved modules: e-auction 
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e  Allthe energy transactions conducted are determined by the outcome of the Vickrey-Clarke-Groves 
auction mechanism, which is a sealed bid type of auction. The auction's algorithms are installed 
within the chaincode of the blockchain network and they are executed periodically, in determined 
time slots. 

e Ina Fabric network the Public Key Infrastructure mechanism is utilized to verify signatures. Each 
participant signing a transaction cannot state that she/he has not signed the content of this 
transaction. 


FR-UC4-03 The system shall support appropriate APIs for the energy trading framework to receive the 
foreseen energy equilibrium of the islands for a specific timeframe in order to 
automatically or manually initiate an energy trading auction. 

Involved modules: e-auction 

Each prosumer runs a software agent that communicates with other software tools which provide 

information regarding the foreseen production and consumption of the building. Based on these 

information, the prosumers are always aware whether they will participate in an auction as bidders (if they 
have a deficit of energy), or they will conduct their own auction as auctioneers (if they have a surplus of 
energy). 


FR-UC4-04 The system shall ensure the payment of the EPES stakeholder who initiated an energy trading 
e-auction and the refund of the losing bidders. 

Involved modules: e-auction 

The processes of bid calculation, bid submission and payment of the corresponding stakeholder are 

performed automatically by the prosumers' agents, therefore the consistency of the participating 

stakeholders is guaranteed. 


FR-UC4-05 e The system shall monitor the security status of the e-auction participants energy 
metering equipment. 
e The system shall deny initialization of an energy e-auction, in case of compromised 
smart meter of the auctioneer. 
Involved modules: BIAD, XL-SIEM, S-RAF, e-auction 
The Blockchain-based Intrusion and Anomaly Detection module is capable of detecting any intrusion by 
monitoring the configuration or log files of the gateways connected to smart meters and to check if the 
smart meters are connected. In case of any intrusion an alert is sent to the XL-SIEM that will provide this 
information to S-RAF to quantify the risk of the incident and make it accessible for the e-auction module. 
FR-UC4-06 The system shall adopt a penalty mechanism to confront participation of malicious 
auctioneers or bidders in the energy trading e-auction. 
Involved modules: e-auction 
In the current version of the Energy Trading System, all the procedures related to the energy market are 
fully automated. Thus, the stakeholders are not capable to perform any malicious actions that will affect the 
Framework's consistency or cause damage to other stakeholders. However, in a future extension of the 
Energy Trading System, users will be granted the capability to perform market-related actions and a penalty 
mechanism will be necessary. This mechanism is presented in this document. 
FR-UC4-07 e The system shall impose a deadline for bid submission in the energy trading e- 
auction, after which no more bids will be accepted 
e The system shall record the energy trading e-auction results in an immutable 
manner 
Involved modules: e-auction 
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The developed chaincode sets strict limitations regarding the permitted time in which the prosumers can 
submit their bids. No other submissions are accepted if the time limit passes. All the transactions conducted 
are recorded in the ledger of the blockchain network which provides immutability, due to the nature of 
blockchain technology. 


3.2.3 Non-functional requirements 

In Table 2, there is a list with all the non-functional requirements that are covered by the Blockchain- 
based Energy Trading System. Those requirements are gathered from D2.2, User & Stakeholder, 
Security and Privacy Requirements. 


Table 2: List of non-functional requirements covered by the Blockchain-based Energy Trading System 


ID Description 


NFR-SEC-07 The system administrative interfaces shall be inaccessible to unauthorized users 

and untrusted parties. 
Involved modules: BIAD 
BIAD uses secured interfaces to communicate with the other tools 

NFR-SEC-11 The system shall be able to use tools to automate configuration and deployment in 

order to minimize human error. 
Involved modules: BIAD 
BIAD has implemented some mechanisms to minimise as much as possible the human 
involvement when installing it. But in any case, small involvements of humans are required to 
configure BIAD prior the installation (see section 6.2) 

NFR-SEC-12 The system shall be able to monitor network devices, operating system, database, 
firewalls as well as software configurations on a regular basis to ensure that their 
configuration is not changed by any unauthorized user. 

Involved modules: BIAD 
One of the objectives of BIAD is to detect any change done in the configuration files of any devices 
through the monitoring of the current state of each device in the blockchain system. 


NFR-TST-01 The system shall be enabled to be automatically testable by software systems 
(continuous testing). 


NFR-TST-02 The system shall be testable by using unit testing, integration testing, security 
testing, performance testing, system testing, and regression testing procedures. 


NFR-TST-05 The system shall be enabled for multi-stage testing, allowing for components to be 
tested both in isolation and collectively. 


Involved modules: BIAD, e-auction 


BIAD and e-auction once have been deployed are up and running so it is possible to test them, but 
there is not any test script, so manual testing procedures can be applied. Some of the components, 
like agent and the chaincode components of BIAD and e-auction, can be tested in an automatic way. 
The unit tests done are described in the section 5. The other tests (integration, system, etc) will be 
done in the context of WP7 and WP8. 
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NFR-DPT-01 The system shall be designed to protect personal data by default and maintain this 
protection throughout the data lifecycle. 


NFR-DPT-02 Only the minimum amount of personal data necessary for fulfilling identified 
purposes shall be processed. 


NFR-DPT-11 The system shall be able to store only sensitive data needed and avoid storing 
unnecessary data. 


Involved modules: e-auction 


All the private data of the participating prosumers are strictly local, and no other prosumers have 
access to them. Participants are identified by pseudo-identities based on their public key and the 
Membership Service Provider (MSP) ID. Only the necessary data for the operation of the auction 
mechanism are being shared during the bidding process (energy request and bid) which are 
cryptographically protected with commitments before being stored to the e-auction’s state. After 
revealing the bids they are stored to the blockchain state because they are necessary for the 
calculation of the e-auction results, but the results including the revealed bids are only restrained 
within the channel for which organizations the market is conducted and not exposed to any other 
members of the blockchain network. 


NFR-DPT-07 The system shall be inaccessible to unauthorized users so that they cannot access 
data either intentionally or accidentally. 


NFR-DPT-08 The system shall be applying end-to-end encryption for data in transit. It must be 
ensured that personal data in transit is protected against active (e.g. replays, traffic 
injection) and passive attacks (e.g. eavesdropping), thus ensuring data integrity. 

NFR-SEC-09 The system shall be able to secure the Application Programming Interfaces (APIs). 
Anonymous access and/or reusable tokens or passwords, clear-text 
authentication or transmission of content, inflexible access controls or 
improper authorizations, limited monitoring and logging capabilities must be 
avoided at all times. 

NFR-SEC-18 The system shall be able to use TLS protocol and certifications mechanisms to 
improve the protection in communication and authentication processes 

Involved modules: e-auction 
The communication between the prosumers is performed within a permissioned Fabric blockchain 
network, meaning that all the participating prosumers are known and identified with X.509 digital 
certificates, rather than anonymous. MSPs are used to define the organizations that are trusted by 
the network members and are also the mechanism that provide members with a set of roles and 
permissions within the network. Also, the client applications offered by the e-auction module 
support https protocol for data in transit. 

NFR-DPT-09 The system shall be able to encrypt data when stored, even when data is stored in 
distributed environments. 

NFR-DPT-10 The system shall be able to keep data in unencrypted form only for the duration 
necessary for the data processing process at hand and no longer neither more 
extensively. 

NFR-DPT-22 The system shall be able to ensure that data are unintelligible except when an 
authorized individual performs authorized operations on that data. 

Involved modules: e-auction 


© SDN microSENSE consortium Page | 21 
Public document 


(x) SDN-uSense 
D4.5 


Version 1.0 


The submitted bids from the prosumers to the Vickrey-Clarke-Groves chaincode, are encrypted with 
commitments and only their hash value is stored to the list of submitted bids that is maintained in 
the e-auction state. Only after, the bidding deadline the bids are revealed and stored in the e-auction 
state, in order to be available for the Vickrey-Clarke-Groves algorithm, that receives the revealed 
bids and produces the e-auction results. 

NFR-DPT-12 The system shall be able to ensure that all random numbers, random file names, 
random GUIDs and random strings are generated in a cryptographically strong 
fashion. Moreover, the system shall be seeding the random algorithms with 
sufficient entropy. 

Involved modules: e-auction 

When a priority table, a new e-auction or a new market are initiated, a UUID is generated that 

uniquely identifies them. This UUID follows RFC-4122! standard. 

NFR-DPT-13 The system shall be able to use only widely accepted cryptographic algorithms and 
implementations and shall be unable to execute implementations that do not 
involve some cryptography experts in their creation. 

NFR-DPT-19 The system shall be able to use tools that employ open-source or public-domain 
encryption methods. 

Involved modules: e-auction 

The identities of a Hyperledger Fabric blockchain network are based on X.509? digital certificates. 

Furthermore, the commitments that hide real bids are generated based on HMAC? commitment 

scheme, utilizing the pseudo-identity of the prosumer (MSP ID + public key). 

NFR-DPT-18 The system shall be able to generate encryption keys offline and securely store 
private keys. 

Involved modules: e-auction 

The certificates of the participating to the energy trading network organizations are generated by 

certification authorities and private keys remain to the possession of the organization and are not 

stored in the system. 

NFR-RL-01 The System shall be able to perform a required function under stated conditions for 
a specified time. The specified time should be defined for each action or operation 
of the system in order for the system to follow these time constraints of operation 

Involved modules: e-auction 

The bidding process of an auction is always conducted under strict time limitation, during which the 

prosumers can submit their bids to the auctioneer. No bids can be submitted once the time 

limitation has passed. The same applies also for the bid revealing, as well as for the energy 
transaction periods. 


NFR-RL-04 The system shall implement mechanisms to ensure resilience against human errors 
and interactions within the system 
Involved modules: e-auction 


The system offers different APIs for different roles of organizations in order to properly interact with 
the chaincodes. Also, there are several controls for different operations, that inform the user with 


1 https://tools.ietf.org/html/rfc4122 

? https://en.wikipedia.org/wiki/X.509 

3 
https://en.wikipedia.org/wiki/HMAC#:~:text=In%20cryptography%2C%20an%20HMAC%20(sometimes,and%20 
a%20secret%20cryptographic%20key. 
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appropriate messages in case of inappropriate interactions (e.g. trying to bid after bidding deadline 
has passed). 

NFR-RL-05 The system shall be SPoF-safe (single point of failure). 

Involved modules: e-auction 

The distributed ledger, a copy of which is available for all the participating prosumers, minimizes the 
possibility of a single point of failure. 


4. System analysis 


The Blockchain-based Energy Trading System is composed of two modules, the e-auction module and 
the Blockchain-based Intrusion and Anomaly Detection module. Both are based on Hyperledger Fabric 
framework [1] which offers the ability to build enterprise blockchain solutions taking into account 
privacy of transactions and permissioned access based on roles that are agreed by the consortium of 
organizations that form the network. In Table 3, the pros and cons of permissioned and permissionless 
blockchain networks are presented, while in Table 4 a comparative analysis of some of the most 
popular blockchain platforms that are used by companies for building blockchain applications is 
provided. 


Table 3: Permissioned vs permissionless blockchain networks 


Category Permissioned Permissionless 
Speed High throughput and medium Low throughput and slow 
latency latency 
Privacy Reading/writing rights can be Can be achieved though 
restricted. cryptographic techniques 
with the cost of lower 
efficiency 


LER 7^ by a pre-defined Public ownership 
LEN ^ of nodes 
| Decentralization | Partially decentralized Fully decentralized 


Cost-effective Not so cost-effective 


Consensus Practical Byzantine Fault Proof of Work or Proof of 
Tolerance (PBFT) protocols, Stake by miners 
tolerating malicious peers and 
trusting the majority consensus 


Table 4: Comparative analysis of different blockchain platforms 


Industry focus Ledger Type Consensus Smart Contracts 
algorithm 
Cross-Industry Permissionless Proof of Work Yes 


TEESE cross-industry Permissioned Pluggable Yes 
R3 Corda Financial Services Permissioned Pluggable Yes 
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Financial Services  Permissioned Probabilistic No 
Voting 

Cross-Industry Permissioned Majority Voting No 

Cross-Industry Permissioned Pluggable Yes 

Cross-Industry Permissioned Chain-based Yes 
Byzantine Fault 
Tolerant 

Digital Asset Permissioned Partitioned Yes 

Management Consensus 

Financial Services Both public & Stellar Consensus Yes 

private Protocol 

Cross-Industry Permissioned Delegated Proof- Yes 

of-Stake 


A permissioned blockchain is more suitable for the Blockchain-based Energy Trading System, because 
of the much higher throughput of transactions, which do not require computational heavy calculations 
that the algorithms of public networks such as Proof of Work usually require to establish trust between 
completely anonymous entities. Also, the permissioned membership, offers more trust among 
participants as they do not transact with unknown entities. Some of the outstanding features that 
differentiate Fabric framework from other distributed ledger technologies that led to its selection for 
the implementation of the blockchain-based energy trading system are the following: 


e  Permissioned architecture 

e Modularity 

e Flexible approach to data privacy with data isolation utilizing “channels” or share private data 
using “data collections” 

e Multi-language smart contract support, Go, Java, Javascript 

e Flexible endorsement model for reaching consensus between required organizations 

e Pluggable consensus mechanism 

e  Queryable data (key-based queries and JSON queries) 

e Open smart contract model 

e Low latency of finality/confirmation 


The basic entities of a Fabric blockchain network are the following: 


e Peers: The peers are the nodes of the blockchain network. In the Energy TradingcSystem’s 
architecture, each node of the network corresponds to a prosumer. Peers are a basic 
component of the network, because they host ledgers and smart contracts, which will be 
explained consequently. 

e Ordering service: Hyperledger Fabric features a node, called an "orderer" which performs the 
accepted transactions ordering, and, along with other orderer nodes, forms an ordering 
service. The ordering service creates blocks of transactions which are distributed to all peers 
for validation. The Fabric's design is based on deterministic consensus algorithms, thus all the 
blocks validated by the peers are definitely final and correct. 
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e Ledger: The ledger contains historic data regarding the results of all the e-auctions that have 
been conducted in the Energy Trading Framework. 

e Membership Service Provider (MSP): Each node is assigned with two keys, a public and a 
private. The pairing of these two keys is used to prove the peer’s identity. The private key is 
used to produce a digital signature on a transaction. The MSP contains the corresponding 
public key and it is used to verify that the signature attached to a transaction is valid. The MSP 
mechanism ensures that the identity of a peer is trusted and recognized by the rest of the 
network, without revealing the corresponding private key. 

e Chaincodes: Also referred as smart contracts. Chaincode defines all the rules under which all 
the transactions of the Energy Trading Framework must be conducted. For example, it 
contains algorithms that determine the outcome of the e-auctions and the incentives 
mechanism. 


4.1 Component model 


4.1.1 E-auction module 

The participants of the developed energy trading platform are prosumers, meaning entities which both 
consume and produce energy, and ESCOs which act as token account administrators for the 
prosumers. Each prosumer can apply to the ESCO to obtain a certain amount of initial tokens, which 
will be the same for all the participants. These tokens will be used by the stakeholders in order to 
conduct the financial transactions in the context of the energy trading. The token accounts are handled 
by the corresponding chaincode, which will be further analyzed later in the document. The prosumers 
are equipped with Photovoltaic panels (PV) and Energy Storage Systems (ESS). Software agents are 
assigned to each prosumer, receiving input from prosumer's infrastructure tools, which perform 15- 
minute PV generation and electric energy consumption forecast. Even though those tools are not 
considered part of the Energy Trading System, they are essential because they provide the input data 
for the determination of the role of the prosumer to the market and the corresponding participation 
parameters (auction parameters for the auctioneers and bid parameters for the bidders). Usually, 
those tools are based on machine learning forecasting algorithms which based on historic data 
timeseries and weather forecasting data, perform short-term production and consumption 
forecasting. 


The communication is performed through a channel of a private Fabric blockchain network. An 
example network with 2 prosumers is illustrated in Figure 2. 
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Figure 2: e-auction Fabric network architecture 


4.1.1.1  E-auction mechanism 

The energy transactions are based on a sealed bid auction mechanism. The auctions take place 
periodically, in certain time slots. The prosumers are always aware whether they will have a surplus or 
a deficit of energy in the next time slot. If they will have a surplus, they will become the auctioneers, 
conducting their own auction, and selling their extra energy. If they will have a deficit of energy, then 
they will take part in the auctions, as bidders, trying to acquire the energy they will need. 


The auction mechanism used is the Vickrey-Clarke-Groves (VCG) auction [2], which is a slight 
differentiation of the traditional Vickrey Auction. The VCG mechanism is a type of sealed-bid auction 
of multiple items (in our case kilowatt hours) and leads to multiple winners. Each bidder submits a bid 
that represents his/her valuation of the items, without knowing the bids of the other bidders. So, the 
auction mechanism gives the bidders an incentive to bid their true valuations, since they are not aware 
of the bids submitted by the rest of the bidders. The VCG auction is suitable for our case, because the 
total energy the bidders request may not be equal to the energy that the auctioneer is selling. Each 
bidder needs a certain amount of energy to satisfy his/her needs, no more or no less than that. Thus, 
the energy that is available for sale needs to be split in the portions that the bidders request. 


At each auction, the auctioneer declares the amount of energy he/she is willing to sell, which is his/her 
surplus of energy. The bidders declare the amount of energy they are willing to buy and their bid in 
tokens. The determination of the winners is based on the following logic: The total energy sold to the 
bidders needs to be less or equal to the energy that the auctioneer sells, while the total value of the 
winning bids (which is the total value of the tokens the auctioneer eventually receives) is maximized. 
An example follows to demonstrate the function of the VCG auction mechanism: 
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VCG auction 

Total amount of energy available for sale: 200 kWhs 
Participating Bidders: 

Bidder 1 [bid = 10 virtual coins, energy request = 50 kWhs] 
Bidder 2 [bid = 100 virtual coins, energy request = 20 kWhs] 
Bidder [bid 5@ virtual coins, energy request = 26 kWhs] 
Bidder [bid 150 virtual coins, energy request = 200 kWhs] 
Bidder [bid 150 virtual coins, energy request 250 kWhs ] 


Auction winners 

Total value of the winning bids:160 

Total energy sold:9@ 

Winning Bidders: 

Bidder 3 [bid = 5@ virtual coins, energy request = 20 kWhs] 
Bidder 2 [bid = 100 virtual coins, energy request = 20 kWhs] 
Bidder 1 [bid = 10 virtual coins, energy request = 50 kWhs] 


Figure 3: VCG auction mechanism demonstration with 3 winners 


Here, the winners are the bidders 1,2 and 3, since the total value of their bids is the maximum possible 
and the sum of the energy they requested is less than the 200 kWh that are available for sale. Bidder 
number 5 obviously cannot be the winner of the auction, since his request of 250 kWh exceeds the 
amount of energy which is available for sale. The energy that was eventually not sold, will be stored 
back to the auctioneer's battery for future use. 


If, for example, bidder number 4 offered 170 tokens for the same energy request, he/she would be the 
winner, since the tokens the auctioneer will receive are maximized: 


VCG auction 

Total amount of energy available for sale: 200 kWhs 
Participating Bidders: 

Bidder 1 [bid = 16 virtual coins, energy request = 5@ kWhs] 
Bidder [bid = 100 virtual coins, energy request = 20 kWhs] 
Bidder 3 [bid 50 virtual coins, energy request = 20 kWhs] 
Bidder [bid 170 virtual coins, energy request 200 kWhs] 


Bidder [bid = 1560 virtual coins, energy request = 250 kWhs] 


Auction winners 

Total value of the winning bids:17@ 

Total energy sold:200 

Winning Bidders: 

Bidder 4 [bid = 170 virtual coins, energy request 200 kWhs] 


Figure 4: VCG auction mechanism demonstration with 1 winner 


It must be noted that in the case that bidder 4 also offered 160 tokens, then the winners would still be 
the bidders 1,2 and 3 because the algorithm chooses the first bidders to maximize the value of the 
winning bids. This will be further explained later, with the demonstration of the incentive mechanism. 
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Figure 5: VCG auction mechanism demonstration, winners defined by priority of bidding 
There are certain strategies which determine: 


1) Inthe case of an auctioneer, the accepted price per kWh. The steps are the following: 
e The auctioneer calculates his/her surplus of energy 
e Calculates how much it cost him/her to produce it using the Levelized Cost of Energy 
(LCOE) factor 
e There is a pre-determined percentage of profit he/she wants to make 
e Calculates the minimum price per kWh he/she would accept in order to make that 
profit 


This way, a prosumer who sells energy will either sell his/her stored energy at a profitable price or 
consume his/her own energy. 


2) Inthe case of a bidder, the bid he/she is going to submit for the energy needed. The steps are 
the following: 
e The bidder calculates his/her deficit of energy 
e Calculates how much it would cost to produce it using the LCOE 
e There is a pre-determined range of percentages he/she want to save by participating 
in the auction (0-15%) 
e Calculates the optimal price for him/her and submits it as a bid 


This way, a prosumer buys energy in a price which ensures that he/she will save coins from the 
transaction. 


These strategies are compatible with the nature of the VCG auction, since they ensure that each 
participant of the e-auction will submit a bid that reflects his/her true valuation of the energy. Before 
the e-auction is initialized, the auctioneer declares the minimum price/kWh which is accepted (as 
calculated according to his/her benefit). The bidders interested already know how much energy they 
need and the price they are willing to offer. If their price is within the restraints of the auctioneer, they 
participate to the auction. Otherwise they will participate in the next auction conducted at the current 
time slot. 
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To summarize the operation of the auction mechanism: 


1. 


10. 


11. 


12. 


13. 


Prosumer's security status is checked by the Intrusion Detection System. Prosumers with 
security issues are not allowed to participate in the market, until the issues are fixed and 
the severity level of the risk assessment regarding their devices is back to acceptable 
values. 

Prosumers are aware whether they have a surplus of energy or not (calculated based on 
input from consumption/production forecasting tools). 

Prosumers with surplus of energy declare that they will conduct e-auctions. The e-auctions 
are conducted based on the priority table. The prosumers with a deficit of energy declare 
that they will participate at the first e-auction. 

The auctioneer informs the potential participants of the e-auction about the minimum 
accepted price per kWh. 

The potential participants are aware of the energy they need and calculate the price per 
kWh they offer (calculated based on the LCOE factor). The bid they submit is also restricted 
by the total amount of tokens they own, meaning they won’t be allowed to submit a bid 
which leads them to bankruptcy (restriction calculated based on input from the bidder’s 
token account). 

The prosumers who don’t meet the auctioneer’s requirements do not participate in the e- 
auction and wait until the next e-auction is initiated. 

The participants of the e-auction submit their sealed bids and the amount of energy they 
are willing to purchase, during a predefined time period. 

After the bidding deadline, the bidders reveal their bids, again during a predefined time 
period. 

When the revealing deadline has passed and all bids have been revealed, the auctioneer 
invokes the chaincode implementing the e-auction mechanism which runs the e-auction 
algorithm and the winners are decided and announced to OTSC tool. 

The OTSC tool of EMO module receives the transactions that derive from the e-auction 
results from the auctioneer and decides upon confirmation/rejection for each energy 
transaction. The energy involved with rejected transactions remains stored in the 
auctioneers Energy Storage System. 

The auctioneer updates the results and the chaincode announces the final results to the 
participants. 

The transfer of energy from the auctioneer to the winners is checked through comparison 
of the measurements from the smart meters monitoring the operation of both the buying 
and the selling stakeholders. 

After the confirmation of energy transactions, the winners invoke the chaincode to 
transfer tokens to the winner’s account. 


Steps 3 through 8 are repeated for the next auctioneer in the priority order until all the auctioneers 
conduct their e-auctions. All prosumers with a surplus of energy will initiate their e-auctions, even if, 
eventually, there will be no prosumers participating. The energy transactions at each time slot refer to 
energy that will be traded in the next time slot. This is why the consumption/production forecasting 
functionality is necessary. At each time slot, there will be multiple e-auctions taking place, always one 
at a time. The e-auctions will be conducted based on the priority table. 
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At the first e-auction of a time slot, the possible scenarios for each bidder who participates are three: 


1. He/she is among the winners, receives the agreed amount of energy at a predefined time 
during the next timeslot and pays the agreed price in tokens. 

2. He/she is not among the winners. 

3. He/she is among the winners, but the OTSC tool of EMO rejects the transaction due to 
microgrid stability issues. 


The bidders who experience scenarios 2 or 3, will participate in the e-auction by the prosumer who is 
next in the priority table. 


The priority order in which the prosumers conduct their e-auctions is a form of incentive, in the sense 
that someone is rewarded for participating in the energy trading process, either by selling or by buying. 
The reward is that, as auctioneers, they conduct their e-auctions earlier than the rest of the 
auctioneers, maximizing the possibilities to sell the energy they have available. 


As mentioned earlier, the e-auction’s algorithm always chooses the first bidders to maximize the value 
of the winning bids. Thus, the priority table is an incentive for the bidders too. The order in which they 
will participate in the e-auction will be determined by the priority table, this time excluding the 
auctioneers. The higher someone is at the priority table, the earlier he/she will participate in the e- 
auction. At the above example, bidder number 4 was lower at the priority table than 1,2 and 3. 


4.1.1.2 Penalty mechanism 

All the actions performed by the prosumers, in the context of the energy market, are fully automated, 
as they are determined by the algorithms run by the corresponding agents and the chaincode. 
Therefore, at this point of the development, there is no need for a penalty mechanism, since the 
consistency of the prosumers is guaranteed. Although, in future extensions of the Energy Trading 
System, users will be granted the capability of handling the prosumer’s actions in the energy market, 
and the outcome of the algorithms run by the agents will be used as suggestions to the user. Thus, a 
penalty mechanism will be necessary because the consistency of the users cannot be guaranteed in 
this case. This subsection presents the penalty mechanism that will be implemented in the future 
extension of the Energy Trading System. 


As far as the priority table is concerned, the prosumers are sorted based on their energy contribution 
to the market (sum of the energy they have sold and bought throughout the whole operation of the 
developed market mechanism and until, but not including, the current timeslot). The first prosumer of 
the table is the first to conduct an e-auction at a specific time slot, the second conducts his/her e- 
auction second and so on. The table contains all the prosumers, no matter if they are buyers or sellers, 
because these roles may and will change through the course of the time slots. 


Table 5: Sample priority table 


PROSUMERS ENERGY CONTRIBUTION(kWh) 


2000 
| 1800 
| 1200 
| 1000 
JE 


| 230 


NB oO We Ul 
OO 0000 
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If a prosumer receives a penalty, then the amount of tokens he/she has to pay replaces his/her Energy 
Contribution (EC) at the table, in the form of a negative number, and his/her EC at that time slot is 
transferred to the Temp column. The cases in which a prosumer is imposed to a penalty will be 
analyzed later. 


For example, if prosumer number 1 has to pay 50 tokens as a penalty, then the table will look like this: 


Table 6: Sample priority table with prosumer 1 being imposed 50 tokens of penalty 


PROSUMERS ENERGY CONTRIBUTION (kWh) TEMP 
2000 0 
1200 0 
1000 0 
0 
0 


750 
230 
-50 1800 


PIN BO WwW UI 


The table is always sorted based on the EC column, so obviously, prosumer number 1 will end up at 
the last place. If, for example, prosumer number 4 has to pay 100 tokens as a penalty, then the table 
will look like this: 


Table 7: Sample priority table with prosumer 1 being imposed 50 tokens of penalty and prosumer 4 being imposed 100 


tokens of penalty 
PROSUMERS ENERGY CONTRIBUTION (kWh) TEMP 
5 2000 0 
3 1200 0 
6 1000 0 
2 230 0 
1 -50 1800 
4 -100 750 


This will result in prosumers number 1 and 4 being last at the order in which they conduct and 
participate in the e-auctions, as a form of punishment. The prosumers will pay their penalty at any 
time slot they can afford it, and once this is done, they will take their place back at the sorting, and 
their Temp column will be zero again. They are not obligated to pay the whole penalty. They can pay 
it in doses through the course of the time slots. In this case the table will be sorted accordingly. For 
example, prosumer number 1 pays the penalty of 50 coins: 


Table 8: Sample priority table with prosumer 1 having paid 50 tokens of penalty and prosumer 4 being imposed 100 tokens 


of penalty 
PROSUMERS ENERGY CONTRIBUTION (kWh) TEMP 
5 2000 0 
1 1800 0 
3 1200 0 
6 1000 0 
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[2 | 230 o 
4 |-100 750 


For simplicity, we assume that the EC of the other prosumers does not change through the course of 
different time slots. 


A prosumer may be imposed to a penalty in two cases: 


e Asanauctioneer, if the energy promised is not delivered to a winning bidder. This confirmation 
will occur from the comparison of the measurements from the smart meters monitoring the 
operation of the selling and the buying prosumer. 

e Asa participant of the e-auction, if the agreed payment is not delivered to the auctioneer's 
token account. 


In the first case, the auctioneer has to return the payment to the winner plus a percentage of it as a 
penalty. In the second case, the bidder has to return the agreed payment to the auctioneer plus a 
percentage as a penalty. 


If a prosumer has a penalty pending, then he/she will be able to participate in an e-auction as a bidder 
normally or conduct his/her own e-auction. He/she will be excluded only from the e-auctions 
conducted by the prosumer he/she owns to. If he/she wants to participate, he/she will have to pay 
his/her penalty to him/her. The energy he/she buys or sells during his "restriction" time, will be 
updated in the temp column. 


If a prosumer owns a penalty: 


e The prosumer is informed by the forecasting tool about the production/consumption balance 
in the next time slot. 

e If there will be a surplus of energy, meaning he/she will conduct an e-auction in the next time 
slot, he/she pays as much of the penalty as possible, with the restriction that he will still have 
a 2096 of his initial coins after the payment. If the penalty is not entirely covered, this process 
will be repeated in the next time slots, until the whole penalty is paid. 

e = If there is a deficit of energy, the prosumer calculates his/her optimal bid as explained before, 
and with the coins remaining, he/she pays as much of the penalty as possible, with the same 
restrictions as with the case of the prosumer with a surplus of energy. 


In the case that, after the course of several time slots the penalty is not yet paid to its entity, the 
bank takes over and pays the rest of the penalty to the prosumer who is owned to, and the rest of 
the debt is transferred to the bank. The prosumer who owns the penalty pays the rest of it to the 
bank in the same way in which he/she pays it to other prosumers, plus a percentage in order to 
ensure a profit for the bank. 


It must be noted that, in the current, fully automated version of the Energy Trading System, the 
prosumers will be sorted only according to their contribution to the market, without taking under 
consideration the Temp column, since the penalty mechanism is not included. 
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4.1.1.3  Vickrey-Clarke-Groves chaincode 
Table 9 presents the Vickrey Clarke-Groves chaincode functions, along with their request type (query 
or invoke) the input parameters and their description. 


Table 9: Vickrey-Clarke-Groves chaincode functions 


Request Input(JSON) 
type Param 


Name Description 


Type 


The Auctioneer parameter is a 
struct representing the peer 
Auctioneer struct node that initializes the e- 


auction. 


The Product parameter is a 
struct with the details of the 
product that is being sold. 


Product struct 


A deposit of tokens is withheld 
from the bidders when the 
submit a bid. 


ReservePrice float 


The timestamp of the 
InitTimestamp timestamp | initialization of the e-auction. 


The timestamp indicating the 
BiddingDeadline timestamp bidding period deadline. 


The timestamp indicating the 


initialize invoke | RevealingDeadline timestamp | revealing bid phase deadline. 


The timestamp indicating when 
the energy transaction is going 
to take place. 


TransactionTimestamp | timestamp 


The timestamp indicating the 
AuctionDeadline timestamp | auction deadline 


The timestamp indicating the 
AwardingDeadline timestamp awarding phase deadline. 


The unique identifier of the 
MarketlD string market to which the auction 
belongs. 


The unique identifier of the 
priority table that keeps the 
PriorityTablelD string contributions to the market for 


each participant organization. 
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Every time an e-auction is 
initialized, a UUID is registered 


get query 


AuctionNum string for that auction which is the 
auctionNum parameter. 
getAuctions query - - - 
AuctionNum string Parameter already described 
The ‘Bid’ parameter represents 
Bid float the number of tokens that the 


submit invoke bidder offers. 
The ‘Amount’ parameter 
Amount integer represents the amount of energy 
in kWh that the bidder bids for. 
AuctionNum string Parameter already described. 
reveal invoke Bid float Parameter already described. 
Amount integer Parameter already described. 
award invoke AuctionNum string Parameter already described. 
settle invoke AuctionNum string Parameter already described. 


Tables 10-15 describe the structures that the chaincode manages: 


Table 10: Vickrey Clarke-Groves auction structure 


Auction 
Name Type Description 
Auctioneer struct is composed of 
n the MSP ID and the Cert ID of the 
Auctioneer struct 


blockchain node that uniquely 
identifies it within the network. 


Product is a struct composed of 
the name of the product (string), 
Product struct the units of the measurement 
(string) and the amount of 
product that is being sold (int). 


The reserve price indicates the 
ReservePrice float minimum amount of tokens/KWh 
that is accepted as a bid. 
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HiddenBids 


Slice of structs 


This is a slice including HiddenBid 
structs, equal to the number of 
submitted bids. 


RevealedBids 


Slice of structs 


This is a slice including 
RevealedBid structs, equal to the 
number of revealed bids. 


InitTimestamp 


timestamp 


The timestamp of the initialization 
of the e-auction. 


BiddingDeadline 


timestamp 


The timestamp indicating the 
bidding period deadline. 


RevealingDeadline 


timestamp 


The timestamp indicating the 
revealing bid period deadline. 


TransactionTimestamp 


timestamp 


The timestamp indicating when 
the energy transaction is going to 
take place. 


AwardingDeadline 


timestamp 


The timestamp indicating the 
awarding phase deadline 


AuctionDeadline 


Results 


timestamp 


struct 


The timestamp indicating the 
auction deadline. 


‘Results’ parameter represents a 
struct that includes the results of 
the e-auction. 


AuctionNum 


string 


Every time an e-auction is 
initialized, a UUID is registered for 
that auction which is the 
auctionNum parameter. 


MarketID 


string 


The unique identifier of the 
market to which the auction 
belongs. 


PriorityTablelD 


string 


The unique identifier of the 
priority table that keeps the 
contributions to the market for 
each participant organization. 


State 


string 


The ‘State’ parameter is a string 
indicating the step of an e-auction 
process and can take the following 
values: 
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‘initialized’, ‘bidding’, ‘revealing’, 
‘refunding’, ‘settling’ 


Table 11: Participant structure 


MspID indicates the ID of the 
MspID string Membership Service Provider of 
the participant organization. 


CertID is the public key of the 


CertID string 
peer 


Table 12: Commodity structure 


The name of the product for sale. 


string 


The units of measurement for the 


Units strin 
g product for sale. 


The amount of the product for 
sale specified in measurement 
units as indicated by ‘Units’ 
parameter. 


Amount integer 


Table 13: Result structure 


The slice ‘Winners’ includes all the 
winning bidders that are 
represented with ‘Participant’ 
structs. 


Winners slice of structs 


The slice ‘RejectedWinners’ 
includes all the winning bidders 
whose energy transactions are 


RejectedWinners slice of structs 
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rejected by the OTSC EMO tool., 
due to grid destabilization issues. 


The total amount of tokens from 


ClearingPrice float 
E all the winning bids. 
EnerevSold — The amount of energy that was 
By 5 sold from all the winning bids. 
The difference between the 
. amount of energy that was for 
EnergyNotSold integer 


sale and the amount of energy 
that was eventually sold. 


The slice ‘Payments’ includes the 
Payments slice of float payment amount in tokens for 
each winner. 


The slice 'Shares' includes the 
Shares Slice of int amount of energy that is assigned 
to each winner. 


Table 14: HiddenBid structure 


HiddenBid 
Name Type Description 
m ind oe 
The ‘HiddenBid’ parameter is the 
HiddenBid slice of byte encrypted representation of the 


actual bid (tokens+amount of 
energy) 


The ‘Nonce’ parameter is a 
Nonce slice of byte cryptographic key that is produces 
to encrypt the bid. 


Table 15: RevealedBid structure 


RevealedBid 


Name Type Description 
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Bidder 


struct 


The bibber is represented by a 
struct of type ‘Participant’ 


Bid 


float32 


The ‘Bid’ parameter represents 
the revealed bid token amount 
that was included in the 
HiddenBid. 


Amount 


int 


4.1.1.4. ERC20 token chaincode 
Table 16 presents the ERC20 chaincode functions, along with their request type (query or invoke) the 
input parameters and their description. 


The ‘Amount’ parameter 
represents the revealed amount 
of energy that was included in the 
HiddenBid. 


Table 16: ERC20 token chaincode functions 


Request Input are 
Name E E Description 
type Param Type 
Name string The name of the token that is initialized. 
The string representation of the token 
initToken invoke | Symbol string | that is initialized. 
The total token units that are available 
TotalSupply float for the token that is initialized. 
Name string Parameter already described. 
; Parameter already described. 
getOwnBalance | query Symbol string y 
The account balance of the peer node 
BalanceOwner | struct | that is querying the blockchain. 
Name string Parameter already described. 
Symbol string Parameter already described. 
The updated account balance of a peer 
update invoke | Amount int node’s account. 
The ‘Account’ parameter is a struct of 
Account struct | type ‘Participant’ that indicates the peer 
node whose account should be updated. 
transfer invoke Name string Parameter already described. 
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Parameter already described. 


Symbol string 
The number of tokens to be transferred 
Amount int from one account to another. 
The ‘From’ parameter is a struct of type 
‘Participant’ that indicates the peer 
From struct | node’s account from which the tokens 
will be transferred. 
The ‘To’ parameter is a struct of type 
‘Participant’ that indicates the peer 
To struct | node’s account to which the tokens will 
be transferred. 
withhold invoke Name string Parameter already described. 
Symbol string Parameter already described. 
The number of tokens to be withheld 
Amount int from the account. 
The ‘From’ parameter is a struct of type 
‘Participant’ that indicates the peer 
From struct | noge's account from which the tokens 
will be withheld. 
release invoke Name string Parameter already described. 
Symbol string Parameter already described. 
The number of tokens to be released to 
Amount int the accounts specified by ‘To’ parameter. 
The ‘To’ parameter is a slice including 
Slice structs of type ‘Participant’ that indicate 
To of the peer nodes’ accounts to which the 
struct | Withheld number of tokens will be 
released. 
apply invoke Name string Parameter already described. 
Symbol string Parameter already described. 
getApplicantsList | query Name string Parameter already described. 
Symbol string Parameter already described. 


Table 17 describes the structure that the chaincode manages: 


© SDN microSENSE consortium 


Public document 


Page | 39 


(x) SDN-uSense 


D4.5 
Version 1.0 


Table 17: Token structure 


Token 

Name Type Description 
Name string The name of the token. 

The string representation of the 
Symbol slice of byte , g rep 

token’s symbol. 

The total token units that are 
TotalSupply float 


available for the token. 


AccountBalances 


Mapl[string, float] 


A map with key the concatenation 
of MspID and CertID strings of a 
peer node owning an account 
and value the account's token 
balance. 


TokenApplicants 


4.1.1.5 Priority table chaincode 


slice of struct 


The token applicants slice 
includes a list with structs of type 
'Participant' that represent the 
peer nodes that have applied for 
an account. 


Table 18 presents the priority table chaincode functions, along with their request type (query or 
invoke) the input parameters and their description. 


Table 18: Priority table chaincode functions 


Request Input 
Name E E Description 
type Param 
initPriorityTable invoke - 
etPriorityTable Uer The unique identifier of the 
E d qos ID String | priority table. 
getPriorityTables query - 
ID string Parameter already described. 
getMarketContribution query THE Participant parametar Is 
€ a struct of type Participant 
Participant struct 
and represents the 
identification information of 
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the Organization’s peer that 
queries the blockchain. 


addParticipantToPriorityTable 


invoke 


Parameter already described. 


updateMarketContribution 


invoke 


ID string 
The ‘Participant’ parameter is 
a struct of type Participant 
and represents the 
Participant struct. | identification information of 


the Organization’s peer that 
should be added to the 
priority table. 


Parameter already described. 


ID string 
The ‘Participant’ parameter is 
a struct of type Participant 
and represents the 
Participant struct | identification information of 
the Organization's peer 
whose contribution to the 
market should be updated. 
The amount of energy that 
should be added to the 
Amount int Participant's contribution to 
the market. 
Table 19 describes the structure that the chaincode manages: 
Table 19: Priority Table structure 
Priority Table 
Name Type Description 
: The unique identifier of the 
ID string 


priority table. 


Participants 


slice of structs 


Includes the list of the 
Organizations' peers that are 
registered to the priority table. 


MarketContribution 


Map[string, int] 


A map with key the concatenation 
of MspID and CertID strings of an 
organization's peer node and 
value the contribution of the 
organization to the market. 
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4.1.1.6 Market chaincode 
Table 20 presents the priority table chaincode functions, along with their request type (query or 
invoke) the input parameters and their description. 


Table 20: Market chaincode functions 


Request Input 
Name q P 


Description 
type Param Type 
The timestamp 


representing the 
ApplicationDeadline | timestamp | deadline of the applying 


phase for the market. 


initMarket invoke 


The unique identifier of 


etMarket uer . 
8 query ID string the market. 


getMarkets query - 


Parameter already 
ID string described. 


The unique identifier of 
a priority table, that 
includes the energy 
contributions to the 


PriorityTablelD string 


apply invoke market. 


This parameter takes 2 
values, either ‘Bidder’ 
or ‘Auctioneer’ and 
Role string represents the role of 
the applicant to the 
market. 


removeFromList ae Parameter already 
inv . 
ID string described. 


Parameter already 
Role string described. 


The ‘Participant’ 
parameter is a struct of 
type Participant and 
Participant struct represents the 
identification 
information of the 
Organization's peer that 
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will be removed from 
the list of Bidders or 
from the list of 
Auctioneers depending 
on the value of ‘Role’ 


parameter. 
Table 21 describes the structure that the chaincode manages: 
Table 21: Market structure 
Market 
Name Type Description 
ID string The unique identifier of the 


market. 


Includes the list of the 
Participants slice of structs Organizations' peers that are 
registered to the market. 


Includes the list of the 
Organizations' peers that are 
registered to the market with 
Bidder role. 


Bidders slice of structs 


Includes the list of the 
Organizations' peers that are 
registered to the market with 
Auctioneer role. 


Auctioneers slice of structs 


Includes the list of the auction 
Auctions Slice of strings unique identifiers that are part of 
a market. 


The timestamp indicating the 
deadline of the application phase 
ApplicationDeadline timestamp for a market. After this deadline 
passes no more participants are 
able to register to the market. 


4.1.1.7  E-auction module APIs 
For the interaction with the blockchain, the e-auction module offers REST APIs for client applications. 
Depending on the role of the organization within the blockchain network, 2 different APIs provide 
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access to the appropriate chaincode functions. The first one is for organizations that are auctioneers 
or bidders and the second one is for ESCO organizations that are administrators of the network's token 
and are responsible for managing the account balances according to the e-auction financial 
transactions. The definition of the APIs is presented in sections 4.1.1.7.1 and 4.1.1.7.2, according to 
OpenAPI 3.0 specification format. 


E  ctioneer-Bidder API 


The auctioneer-bidder API enables the organizations to interact both with the ERC20 chaincode and 
the Vickrey-Clarke-Groves chaincode. Through the available endpoints, they are able to apply for a 
token account if they do not already have one, retrieve their own balance at any time and transfer 
tokens from their account to another, in order to complete the financial settlements that derive from 
e-auction results. 


ERC20 token Token account processes Rs 


8 


ON /apply Apply for token account 


GET /getBalance Each organization can retriece its own balance 


ST {transfer Transfer tokens to another organization's account 


Vickrey Clarke Groves auction Vickrey Clarke-Groves auction lifecycle processes a 


a 


T /initVickreyCGAuction Initialize a new Vickrey auction 


Ê 


/getVickreyCGAuction Retums Vickrey auction state 


3 


ST /VCGsubmitSealedBid Submit commitment of bid to a Vickrey auction 


ST /VCGreveal Bidders reveal their bids after the bidding deadline passes 


ST /VCGaward Auctioneer invokes the chaincode function that implements algorithm to award winners 


3 


ST /VCGsettle Winners transfer tokens corresponding to their bid to the Auctioneer's account 


Market Market retrieval and registration processes Vv 


/getMarkets Returns list of Markets 


| /applyToMarket Apply to an existing market as Auctioneer or Bidder 


Priority Table Priority table retrieval - 


GET /getPriorityTable Retums list of Priority Tables. 


Figure 6: Auctioneer-Bidder API endpoints 
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/apply Apply for token account | 


Parameters Try it out 


No parameters 


Request body "=" application/json v 


Name and symbol of the token for which the application is done 


Example Value Schema 


{ 
"Name": "string", 


"Symbol": "string" 
} 


Responses 
Code Description Links 
200 No links 


successful operation 


text/plain Y 


Controls Accept header. 


Example Value Schema 
string 
400 No links 
Bad request 
Media type 


500 No links 
Unable to invoke apply in ERC20 chaincode 


Figure 7: /apply request parameters and responses 
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| 
/getBalance Each organization can retriece às vam balante 
ji 
Parameters Try it out 
Name Description 
à remores 
— Name of the token 
string 
(query) m 
name of the ken 
g renored 
ape String representation of the token symbol 
string 
(query) 
symbo 
msplD * "rti identifier of the organization's MSP 
string 
(query) meniD - n cp 
* requeed 
= identifier of the organization's certificate 
string 
(query) n 
D - identihe: 
Responses 
Code Deecription Links 
200 No links 
successful operation 
application/json v 
Example Value | Scherma 
400 No links 
Bad request. One or more parameters missing 
500 No links 
Unable to query the blockchain 
Figure 8: /getBalance request parameters and responses 
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EM /transfer Tr 


Parameters Try it out 


kens to another organizalian's socount 


No parameters 


Request body “=== application/json { 


Name and symbol of the token, amount of token units, identities of sender and receiver 


Example Value | Scherma 


"espID": "string", 
"certiD": "string" 


Responses 
Code Dsecription Links 
200 No links 
successful operation 
Exemple Value | Scher: 
string 
400 No links 
Bad request 
500 No links 
Unable to invoke transfer in ERC20 chaincode 
Figure 9: /transfer request parameters and responses 
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| Post | /initVickreyCGAuction Initialize a new Vickrey auction 


| Parameters 


No parameters 


| Request body PW% 


Parameters needed to initialize a new Vickrey auction 


Example Value | Schema 


“Auctioneer 


Try it out 


application/json v 


| Responses 
Code Description Links 
200 No links 
successful operation 
Example Value | Schema 
string 
400 m No links 
Bad requi 
500 No links 
Unable to invoke initialize in VickreyAuction chaincode 
Figure 10: /initVickreyCGAuction request parameters and responses 
EZB /getVickreyCGAuction Returns Vickrey auction state 
Parameters Try it out 
Name Description 
auctionNum * "8°" io of Vickrey auction 
string 
auctionNum - UUID of n 
Responses 
Code Description Links 
200 No links 
successful operation 
text/plain v 
Example Value | Schema 
string 
400 No links 
Bad request. AuctionNum parameter missing 
500 No links 


Unable to query the blockchain 


Figure 11: /getVickreyCGAuction request parameters and responses 
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/VCGsubmitSealedBid Submit commitment of bid to a Vickrey auction 


Parameters Try it out 


No parameters 


Request body =s application/json M 


Parameters needed to submit bid 


Example Value | Schema 


H 


"AuctionNum": "st 
"Bid" 
“amount”: 

3 


Responses 
Code Description Links 
200 No links 


successful operation 


text/plain v 


Example Value | Schema 


string 


400 No links 
Bad reques! 


500 No links 


Unable to invoke submit in VickreyAuction chaincode 


do 


Figure 12: /VCGsubmitSealedBid request parameters and responses 
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| /NCGreveal 


Parameters Try it out 


No parameters 


Request body a application/json 


Parameters needed to reveal bid 


Example Value Schema 


t 


Responses 
Code Description Links 
200 No links 


successful operation 


text/plain v 


Example Value | Schema 


string 


400 No links 
Bad request 


500 No links 
Unable to invoke reveal in VickreyAuction chaincode 


Figure 13: /VCGreveal request parameters and responses 


/VCGaward 


Parameters Try it out 


No parameters 


Request body " application/json 


Parameters needed to award winner 
Example Value | Schema 


€ 


"AuctionNum": "string" 


H 


Responses 
Code Description Links 
200 No links 


successful operation 


M 


text/plain v 


Example Value | Schema 


string 


400 


Bad request 


500 No links 


Unable to invoke award in VickreyAuction chaincode 


Figure 14: /VCGaward parameters and responses 
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kaa /NCGsettle a 


Parameters Try it out | | 


No parameters 


Request body '*?*'** applicati 


Parameters needed for financial settlement of Vickrey auction 


Example Value Schema 


t 


"AuctionNum": "string" 


5 


Responses 

| 
Code Description Links 
200 No links 


successful operation 


text/pl 


Example Value | Schema 


string 


400 No links 
Bad request 


500 


Unable to invoke settle in VickreyAuction chaincode 


Figure 15: /VCGsettle request parameters and responses 


Market Market retrieval and registration processes +. 


/getMarkets Returns list of Markets 


Parameters Try it out 


No parameters 


Responses 
Code Description Links 
200 No links 


successful operation 


text/plain v 


Example Value | Schema 


string 


500 No links 
Unable to query the blockchain 


Figure 16: /getMarkets request responses 
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| 
| | Post | /applyToMarket Apply to an existing market as Auctioneer or Bidder 

E EX 

| Parameters | Tryit out 


No parameters 


| Request body 7" application/json v 


The request body includes the parameters that are needeed to apply to a market 


Example Value | Schema 


| Responses 
Code Description Links 
200 No links 


successful operation 


text/plain v 


Example Value | Schema 


400 No links 


Bad request 


500 No links 


Unabie to invoke apply in market chaincode 


Figure 17: /applyToMarket request parameters and responses 


Priotity Table Priority table retrieval RS 


| /getPriorityTable Returns list of Priority Tables 


Parameters Try it out 


No parameters 


Responses 

| 
Code Description Links 
200 No links 


successful operation 


text/plain v 


Example Value | Schema 


500 No links 
Unable to query the blockchain 


Figure 18: /getPriorityTable request responses 


EE sy 


The ESCO API provides interaction only with the ERC20 chaincode, as the ESCO acts as an administrator 
for the token accounts and does not take part in energy trading transactions. Through this API, the 
ESCO is able to initialize a new token, create accounts and initialize account balances, retrieve the list 
of organizations that apply for account creation, initialize a new market, initialize a priority table that 
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keeps the energy contribution of each organization and retrieve the list of priority tables (should be 
only one per channel of organizations). 


ERC20 token Token account processes 


ACUE /initToken Initialize token 


GET /getApplicants Retrieve list of applicant organizations for generating token accounts 


POST /updateBalance Update balance of an organization's account 


= 
£5 
- 
- 
m 
Ls 


wee) /initMarket Initate a new market 


Priority Table 


POST /initPriorityTable Initate a new priority table to hold the organizations' energy contribution to the market 


GET /getPriorityTable Returns list of Priority Tables. 


Figure 19: ESCO API endpoints 
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finitToken Initialize token 


Parameters Try it out 


No parameters 


require 


Request body application/json v | 


Name, symbol and total amount of the token to be initialized 
Example Value Schema 
{ 


"Name": "string", 
"Symbol": "string", 


"TotalSupply^: 6 
} 


Responses 
Code Description Links 
200 No links 


successful operation 


Media type 


text/plain v 


Controls Accept bender 


Example Value Schema 
string 
400 No links 


Bad request 


Media type 


500 ; j No links 
Unable to invoke apply in ERC20 chaincode 


Figure 20: /initToken request parameters and responses 
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| 
HEM /getApplicants Retrieve list of applicant organizations for generating token accounts 
E 
Parameters Try it out 
Name Description 
name * "aurea 
: Name of the token 
string 
(query) 
name - Name of the token 
symbol * “as: 
Y String representation of the token symbol 
string 
(query) 
symbol - String repi ntation of the token s 

Responses 
Code Description Links 
200 No links 

successful operation 

Media type 

text/plain v 
Example Value Schema 
string 

400 No links 

Bad request. One or more parameters missing 
500 No links 

Unable to query the blockchain 

Figure 21: /getApplicants request parameters and responses 
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ES JupdateBalance Update balance of an organization's socount 


Parameters Try it out 


No parameters 


Request body “= application/json { 


Name and symbol of the token, amount of token units, identities of sender and receiver 


Example Value | Scherma 


Responses 
Code Dsecription Links 
200 No links 
successful operation 
Example Value | Schema 
string 
400 No links 
Bad request 
500 No links 
Unable to invoke update in ERC20 chaincode 
Figure 22: /updateBalance request parameters and responses 
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Parameters Try it out 


No parameters 


Responses 
Code Description Links 
200 No links 
successful operation 
text/plain v 
Controls Accept header. 


Example Value | Schema 


500 No links 


Unable to invoke initMarket in market chaincode 


Media type 


Figure 23: /initMarket request responses 


/initPriorityTable Initate a new priority table to hold the organizations! energy contribution to the market ë 


Parameters Try it out 


No parameters 


Responses 
Code Description Links 
200 No links 
successful operation 
Mesia type 
text/plain v 


Controls accept header 


Example Value Schema 


500 No links 
Unable to invoke initPriorityTable in priorityTable chaincode 


Media type 


Figure 24: /initPriorityTable request responses 


4.1.2 Blockchain Based Intrusion and Anomaly Detection module 

The Blockchain Based Intrusion and Anomaly Detection system (BIAD) is a peer-to-peer network used 
to monitor the activity and performance of a set of devices (i.e. smart meter, IEDs, RTUs...), maintaining 
their status and integrity, and alerting when unusual operation is detected. This is done by detecting 
changes in log files and in firmware and configuration files in different devices and monitoring the 
current state of each device in the blockchain system, compiling robust transaction records. Another 
functionality allows the system administrators to perform periodically on-chain availability- 
connectivity tests. 
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The blockchain network is developed using Hyperledger Fabric, an open source project from the Linux 
Foundation to easily set up a distributed ledger focused on traceability. The network has the following 
components (See Figure 25): 


e Peer Node 


For this project case it has been set up only a single peer for a single organization, responsible for 
all the monitoring interactions with tested devices. 


e Orderer Node 


It is the central communications node, responsible for maintaining state and consistency of the 
ledger and mining and distribution of the blocks. There is also a single orderer working for this 
proof of concept. 


e Certificate Authority Server 


Manages and provides the access control to the network functionalities through Enrolment 
Certificates. 


e  Chaincode 


The chaincode is a program which provides logic to the peers, a smart contract, and is necessary 
to be able to read and update the ledger state and create transactions. In this case, the chaincode 
is developed in the Go programming language and it is installed on a channel of the blockchain. Its 
functionalities are ejected in the peers that belong to that channel. 


Furthermore, there some other components external to the blockchain network: 
e REST API Server 


It works as Hyperledger Fabric wallet, it is supported by Fabric SDK and it can be used to create, 
sign and send transactions to the ledger. In this case, it works as another service, but it can be 
integrated with the own agent. Provides authentication using token-based authentication. 


e Explorer Server 


This component is a daemon which sets up a web server to visualize the performance dashboard 
of the ledger. It is using Hyperledger Explorer, another project from the Linux Foundation. 
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AN v v 
P REST API) 


Agent Transaction 


signed 
Explorer 
web server | 


Blockchain Infrastructure 


Peer node Peer node 
1 
Logs Org2 Org 
Chaincode Chaincode 


Event | V [teaver] ES aem 
listener | se 
Orderer-node Authority Org1 
| 
Alerts Chaincode = 


[E 


SIEM 


Figure 25. Blockchain Based Intrusion and Anomaly Detection system components 


There are two types of requests in Hyperledger Fabric, invoke and query, the first one needs to change 
the ledger's state so it creates a new block, the second one is only reading function, so it does not mine 
a new block and it causes faster performance. Figure 22 shows the specification for each available 
function: 


Table 22 Functions from the chaincode 


Request | Input (JSON 
Name $ putt ) Description 
type Param Type 
registerDevice invoke dvclD string Registers a new device to be monitored 
: Gets state from a previously registered 
getDevicelnfo query dvciD string | device 
getDeviceHistory | query dvciD string Gets history from a device asset 
bar, : Checks last device update to be less than a 
connectivity invoke _ E periodot time 
. dvclD string | Registers a new hash related to an existing 
registerHash invoke path string | device 
hash string 
hashlD tri 
ae j ring There are two input options 
hash string 
updateHash invoke dvcID string | Updates state of a previously registered 
path string | hash 
hash string 
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getHashinfo query hashlD string Gets state from a previously registered hash 
dvciD string 
; Registers a new record related to an existin 
registerRecord | invoke | max (opt) [int i E 8 
min (opt) int SNIGE 
value (opt) | int 
recordID string 
value int Updates state of a previously registered 
updateRecord invoke AvéiD string sae P PB 
param string 
value int 
f Gets state from a previously registered 
getRecordinfo query recordiD string | record 
getAlertinfo query alertiD string Gets state from an existing alert 


Tables 23-26 describe the structures that the chaincode manages: 


Table 23 Device structure 


Device 
Name Type Description 
DvclD string Device unique identifier 
Hashes [ ]*HashModel Array of associated hashes 
Records [ ]*Record Model Array of associated records 
Alerts [ ]*AlertModel Array of associated alerts 
Status bool Indicates device availability 


Table 24 Hash structure 


Hash 
Name Type Description 
HashiD string Hash unique identifier 
DvclD string Associated device identifier 
Path string Hashed file path in the device 
Value string Last hash value received 
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Table 25 Record structure 


Record 
Name Type Description 
RecordID string Record unique identifier 
DvclD string Associated device identifier 
Param string Monitored record description 
Value float32 Last record value received 
Max float32 Record maximum limitation 
Min float32 Record minimum limitation 
Table 26 Alert structure 
Alert 
Name Type Description 
AlertID string Alert unique identifier 
DvclD string Associated device identifier 
HashiD string Associated hash identifier 
RecordID string Associated record identifier 
Class string Message describing the alert 
PrevValue string Value read from ledger when anomaly was detected 
RcvValue string Value received from client when anomaly was detected 
Max float32 Reached maximum limitation when record anomaly was detected 
Min float32 Reached minimum limitation when record anomaly was detected 


In order to clarify the behavior of the BIAD, Figure 26 presents a sequence diagram with the flow that 
follows BIAD in an operation. 
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RTU Agent Wallet REST API CA Org1 Peer Org1 Orderer Chaincode Event listener 
Authentication Request 
TT 
Verify user 
+ 
t 200 OK 
Send token 
o 
Hash files 
Request RegisterHash 
eS 


Create and sign 
transaction 


Invoke RegisterHash 


OT E a 
Validate transaction 
RegisterHash 
—————————X 
Validate transaction 
Alert (in case of attack) 
+ —————— 
Alert event 
——————X 
Alert normalization 
Alert 
+ 

Mine new block 

and broadcast 

New block 
+ 
Transaction callback 
_)—_— ——— 
Response alert 
RTU Agent Wallet REST API CA Org1 Peer Org1 Orderer Chaincode Event listener SIEM 


Figure 26: BIAD behaviour model 


4.2 Interfaces model 


4.2.1 External interfaces with other SDN-microSENSE application plane modules 


4.2.1.1 Communication of e-auction module with EMO 
The OTSC EMO tool provides a Rest API to validate if changes proposed by the e-auction module of 
the Energy Trading System are feasible from an electrical point of view: 


Table 27: EMO — e-auction interface 


nterface name: OTSC EMO - e-auction 


Description his interface lets us to evaluate the feasibility in electrical terms from a set of proposed 
changes for the grid model. 
OTSC EMO 


e-auction 


REST API 


Developed 


List of energy trading actions to validate 
Example: 


© SDN microSENSE consortium Page | 62 
Public document 


SDN-ySense 
D4.5 
Version 1.0 


"id"r 2, 

"energy": 40.0, Amount of energy exchanged (kWh) 

"time action": "18/08/2020 09:00:00.000" Time when the action sould start 

"time": 15.0 Time of the transaction (s) 

"seller node": "prosumerl" Node to identify the seller on the grid 

"buyer node": "prosumer4" Node to identify the buyer on the grid 

"seller baseline power": 10.0, Baseline power consumtion without the energy trans. (kW) 
"buyer baseline power": 10.0 Baseline power consumtion without the energy trans. (kW) 


"id": 2, 

"energy": 20.0, 

"time action": "18/08/2020 09:00:00.000" 
"time": 15. 

"seller node": "prosumer2" 

"buyer node": "prosumer3" 

"seller baseline power": 


"buyer baseline power": 


As it is going to be accessed from out of the OTSC EMO virtual machine (VM15), the 
important thing here is the URL for external access: 


In Figure 27, there is an example about how to do a call to this Rest API: 


Post spaces lae save = 


Body@ Pre-request Script 


coded Brew O brary Beauty 
00:00 000 
ler. baseline, power”: 19.9, 
"buyer baseline power": 19.0 
90:00 .008 
“seller baseline pos q 
"buyer. baseline power": 15.0 
ï 
1 
Body Cookies Headers (4) Test Resuts O sms 200K Time: 35403 Sue 1728 Save Response © 
Premy Rew Preview Vauslre SON © 5 ma 
Ê I 
t 
"iei i 
"result": "Ok" 
» 
{ 
"tar; 2 


D "result": "KO" 


Figure 27 Example request of Market Validator 
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4.2.1.2 Communication of e-auction module with S-RAF 


The e-auction module interacts with S-RAF for acquiring the latest risk assessment results, as those 
have been generated considering the vulnerabilities of the infrastructure and the threats detected by 
the XL-EPDS infrastructure. As presented in Figure 1 for the blockchain-based energy trading system 
within the SDN-microSENSE architecture, the e-auction module considers the information of the risk 
levels, which is generated on asset-basis, in order to decide whether to deny participation to the 
market to organizations that face cyber risks. 


To do so, the e-auction module subscribes to the KAFKA component of S-RAF for consuming the risk 
assessment information. Table 28 summarizes the necessary interface details for materializing this 
interaction. 


Table 28: e-auction — SRAF interface 


Interface name: e-auction module — S-RAF 


Description The objective of this interface is to make available the risk assessment 
the interface 


Consumer e-auction module 


components 


Used Technology KAFKA 
Developed 


Input data Events from XL-EPDS infrastructure (via CIS). 


Output data Risk assessment results generated on asset-basis containing information 
o nn 
[Constraints [None 

UBITECH to provide more information to the developing team of e- 
auction module to ease integration. 


Responsibilities 


Documentation link More details can be found in D3.5. 


4.2.1.8 Communication of Blockchain-based Intrusion and Anomaly Detection with XL-SIEM 

XL-SIEM uses syslog as a mechanism for receiving information. The provided script rsyslog.sh prepares 
the rsyslog to send information to the XL-SIEM. Once the rsyslog has been properly installed and 
configured, it is necessary to install the module which listens for alerts from the BIAD and converts 
them to a readable format for the XL-SIEM. To run this module, it is required to have NodeJS installed 
in the SO as well as some libraries with npm install. 


This component listens for the alerts generated in the Blockchain based Intrusion and Anomaly 
Detection module, that have a predetermined format and converts them into a format, which is 
understood by the XL-SIEM. The format of the alert is not specified in this deliverable, in order to 
ensure the protection of the sensitive information. 
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The word “BIAD” in the alert will be automatically included by rsyslog to inform XL-SIEM the detector 
of the alert. 


Focusing on the technology, the connection with the XL-SIEM is made using NodeJS as programming 
language as it has been introduced before. The script listens for events from the Hyperledger Fabric 
Network and writes a new line in /var/log/biad.log file. Then, the rsyslog daemon detects the changes 
in this file and sends the new line to the XL-SIEM. This software can be easily adapted to send 
information to any endpoint, not necessarily the XL-SIEM. 


Table 29: BIAD - XL-SIEM interface 


Interface name: Blockchain based Intrusion detection - XL-SIEM 
Description The objective of this interface is to send the alerts generated by the 
Component providing | XL-SIEM 

e 
components 


Used Technology Rsyslog 


[State Developed OO  —  - 
[Commams — [Nome — — — SS 


4.2.2 External interfaces with SDN-microSENSE infrastructure plane modules 


4.2.2.1 Connection of e-auction module with RPI of smart meter 

Each prosumer participating in the network is represented in the e-auction processes by an agent, that 
utilizes information such as the security status of the prosumer's smart meter and the energy balance 
forecasting provided by external tools, in order to take decisions regarding the role in the market 
(auctioneer/bidder), as well as the price of selling/buying. The flow chart in Figure 28, summarizes the 
algorithms executed by the agents in each time slot: 
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Agent Algorithm 


Auction ends tem € * 
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Figure 28: Agent algorithm 


It must be noted that in Figure 24 the penalty mechanism functionality is included, which is not part 
of the current version of the Energy Trading Framework. Apart from the penalty mechanism, all the 
procedures demonstrated in the flow chart are implemented in the current version. The flow chart 
was designed with the aim to provide the reader with the general overview of the algorithms run by 
the agents. 


The flow chart in Figure 29, demonstrates the algorithm followed by the agents in order to determine 
the way in which they will pay the penalties imposed to them, and refers only to the extension of the 
Energy Trading Framework, in which the penalty mechanism will be included. 
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Figure 29: Penalty paying algorithm 


4.2.2.2 Connection of Blockchain Based Intrusion and Anomaly Detection module with RPI of smart 
meter 

The Blockchain-Based Intrusion and Anomaly Detection (BIAD) module requires an agent to send 

information to the Blockchain part (See Section 4.1.2). This agent can be installed in any device (in the 

context of the SDN-microSENSE project Raspberry PI based smart meter is going to be used in order to 

be able to do the proof of concept) that is about to be monitored and it must be configured to connect 

with the BIAD. Further information about the installation process is provided in section 6.2. 


The BIAD agent has been developed using C programming language, so it can be compiled in any device 
having a C compiler. Furthermore, C is one of the fastest languages, which is a crucial aspect, 
considering that the target devices are usually constraint in terms of processor power, RAM memory, 
or even battery. Consequently, developing a lightweight agent is a fundamental requirement within 
the BIAD component. 
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As part of the configuration, some file paths must be given to the agent. The BIAD agent then 
systematically looks for these files in the filesystem and hashes them. Once this hash has been 
calculated, the next step is to submit it to the Blockchain and perform the comparison as it has been 
previously discussed. The BIAD agent can bind as many files as required and with any format, so 
different files can be monitored, such as: configuration files, log files or even the whole firmware. 


Furthermore, the agent checks useful kernel information, such as: number of processes, RAM usage, 
and uptime. This information is also sent to the BIAD — peer node to be analyzed. It is important to 
notice that the BIAD is agnostic when it comes to this information, because is the BIAD who adds the 
intelligence to this information. The agent works only as a lightweight daemon who passes information 
to the BIAD. 


As it will be explained in the section 6.2, all the configuration process is made directly over the code 
before compilation, so no information is retrieved from other sources. By doing it this way, we can 
later remove every evidence of the agent installation, except the executable, so it can be more easily 
hidden in the system. A process-hiding mechanism has also been included in the agent, to hide the 
subsequent process from being shown with the rest of system processes and this system has been 
tested in Debian systems. This strategy is considered security-by-obscurity, but we have considered 
that any extra occultation layer is welcomed. At the end, time is crucial in the solution, and the most 
time an attacker spends in detecting the agent, the better. 


5. System verification 

To verify that the Blockchain-based Energy Trading System meets its requirements, several unit tests 
have been defined and executed. Unit testing is an integral part of TDD (test-driven development) 
procedures, as it facilitates designing robust software components by finding and fixing defects in the 
early stages of software development lifecycle. The flow-chart of Figure 26, presents the procedure of 
TDD. 


© SDN microSENSE consortium Page | 68 
Public document 


(x) SDN-uSense 
D4.5 


Version 1.0 
[se Write a unit test 


Pass Run the test 


Test fails 


Modify the code 
| Run the test 


Test fails 


Figure 26: TDD procedure 


In sections 5.1 and 5.2, the unit tests for both e-auction module and Blockchain Based Intrusion and 
Anomaly Detection module are presented, using test case tables that include description of the unit 
test, the related requirements for which the unit test was written, the priority of the test for the 
development of the software, the pre-conditions that should be fulfilled to run the test, the test steps 
that compose the unit test, the input data for each step, the results after executing each step and the 
result of the whole unit test. 


5.1 E-auction module unit tests 
Table 30: E-AUCTION_01 unit test 


Test Case | E-AUCTION 01 Component E-auction module of 
ID energy trading 
framework 


Descriptio | ESCO company is responsible for managing ERC20 token accounts. This test showcases 
n the ability of ESCO organization to initialize a token, create and update user accounts. 
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Req ID FR-UC4-04 Priority High 

Prepared | CERTH Tested by CERTH 

by 

Pre- e Each component of the e-auction has to be up and listening on their respective 

condition( port, which includes at least an orderer, a peer for the ESCO organization, one 

s) or more peers for prosumers and a couchdb for each peer. 

e The ERC20 chaincode must be installed and instantiated on the e-auction 
channel of the blockchain network. 
e The application of each organization is running 

Test steps 

1 The peer of ESCO organization sends a POST HTTP request to initialize a new token, with 
the name of the token, the symbol of the token and the amount of token units that 
correspond to the total supply. 

2 The peers of each prosumer organization (Org1, Org2 and Org3), apply for token account 
with an HTTP POST request, including the name and the symbol of the token in the 
request body. 

3 After applying each prosumer should be able to retrieve the balance of its own with an 
HTTP GET request with the name and the symbol of the token as URL parameters. The 
initial balance should equal to O. 

4 The ESCO retrieves the list of applicant organizations, through an HTTP GET request with 
the name and symbol of the token as URL parameters 

5 The ESCO organization's peer updates the balances of the applicants with 500 tokens for 
each account as an initial amount. This action is performed with an HTTP POST request 
with the name and symbol of the token, the amount of the tokens and the prosumer's 
identification information (MSP ID and CertID). 

5 At this stage, each prosumer retrieves its balance, that should be equal to 500 tokens. 

Input e Step1 

data 

{ 
"Name": "tok", 
"Symbol": "BT", 
"TotalSupply": 1000000 
) 
e  Step2 
{ 
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"Name": "tok", 
"Symbol": "BT" 
} 
e  Step3 


name=tok 
symbol=BT 
msplD=Org1MSP 
certID=eDU...VVT 


e Step4 
name-tok 
symbol-BT 


e Step5 


"Name": "tok", 

"Symbol": "BT", 

"Amount": 500, 

"From": { 
"Mspld":"Org1MSP", 
"Certid":"eDU...VVT" 


e Step6 
name=tok 


symbol=BT 
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Result 


e Step1 


localhost:8090/initToken 


Body 


form-data x-www-form-urlencoded © raw binary 


Pretty 


Transaction ID: 
XI(EXTRA string=3b97bcb911efe606f134e29fa581337657a59763530806f1061c311b9329b39f 


y 
J 


e  Step2 
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* localhost:8091/apply 


POST , localhost:8091/apply 


Body 


form-data x-www-form-urlencoded © raw binary 


Pretty 


ansaction I 
string=a6bdd5c53a5591290259a2d284a244e8748c76542e62812665bb2db4f1daec8a 


M localhost:8091/getBalance?name-tok&symbol-BT&msplID-Org1MSP&certlID-eDUwOTo6Q049VXNIcjFAb3]nMSSleGFtcGxILmNvbSxMPVNhbiBGcmFuY; 


Params 
KEY 


name 


bo 


FtcGxlLmNvbSxMPVNhbiBGcm| 


e  Step4 
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+ localhost:8090/getApplicants?name=Blocktion Token&symbol-BT 


etApplicants?name=tok&symbol=BT 


name 


localhost:8090/updateBalance 


form-data x-www-form-urlencode ® raw binary 


ansaction 
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091/getBalance?name-tok&symbol-BT&msplID-Org1MSP&certlID-eDUwOTo6Q049VX. inMSSleGFtcGxILmNvbSxI 


name 


BmRmmBG 


eGFtcGxiLir 
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Test Case | Achieved 

Result 

Test Case | E-AUCTION 01 Component E-auction module of 

ID energy trading 

framework 

Descriptio | ESCO company is responsible for managing ERC20 token accounts. This test showcases 

n the ability of ESCO organization to initialize a token, create and update user accounts. 

Req ID FR-UC4-04 Priority High 

Prepared | CERTH Tested by CERTH 

by 

Pre- e Each component of the e-auction has to be up and listening on their respective 

condition( port, which includes at least an orderer, a peer for the ESCO organization, one 

s) or more peers for prosumers and a couchdb for each peer. 

e The ERC20 chaincode must be installed and instantiated on the e-auction 
channel of the blockchain network. 
e The application of each organization is running 

Test steps 

1 The peer of ESCO organization sends a POST HTTP request to initialize a new token, with 
the name of the token, the symbol of the token and the amount of token units that 
correspond to the total supply. 

2 The peers of each prosumer organization (Org1, Org2 and Org3), apply for token account 
with an HTTP POST request, including the name and the symbol of the token in the 
request body. 

3 After applying each prosumer should be able to retrieve the balance of its own with an 
HTTP GET request with the name and the symbol of the token as URL parameters. The 
initial balance should equal to O. 

4 The ESCO retrieves the list of applicant organizations, through an HTTP GET request with 
the name and symbol of the token as URL parameters 

5 The ESCO organization's peer updates the balances of the applicants with 500 tokens for 
each account as an initial amount. This action is performed with an HTTP POST request 
with the name and symbol of the token, the amount of the tokens and the prosumer's 
identification information (MSP ID and CertID). 

5 At this stage, each prosumer retrieves its balance, that should be equal to 500 tokens. 
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e Step1 
{ 
"Name": "tok", 
"Symbol": "BT", 
"TotalSupply": 1000000 
} 
e Step2 
| 
"Name": "tok", 
"Symbol": "BT" 
} 
e  Step3 


name-tok 
symbol-BT 
msplD=Org1MSP 
certID=eDU...VVT 


e  Step4 
name-tok 
symbol-BT 


e Step5 


"Name": "tok", 

"Symbol": "BT", 

"Amount": 500, 

"From": { 
"Mspld":"Org1MSP", 
"Certid":"eDU...VVT" 


e  Step6 
name=tok 


symbol=BT 


© SDN microSENSE consortium Page | 77 
Public document 


44) SDN-uSense 


D4.5 
Version 1.0 


Result 


e Step1 


localhost:8090/initToken 


Body 


form-data x-www-form-urlencoded © raw binary 


Pretty 


Transaction ID: 
XI(EXTRA string=3b97bcb911efe606f134e29fa581337657a59763530806f1061c311b9329b39f 


y 
J 


e  Step2 
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* localhost:8091/apply 


POST , localhost:8091/apply 


Body 


form-data x-www-form-urlencoded © raw binary 


Pretty 


ansaction I 
string=a6bdd5c53a5591290259a2d284a244e8748c76542e62812665bb2db4f1daec8a 


M localhost:8091/getBalance?name-tok&symbol-BT&msplID-Org1MSP&certlID-eDUwOTo6Q049VXNIcjFAb3]nMSSleGFtcGxILmNvbSxMPVNhbiBGcmFuY; 


Params 
KEY 


name 


bo 


FtcGxILmNvbSxMPVNhbiBGcm 


e  Step4 


© SDN microSENSE consortium Page | 79 
Public document 


44) SDN-pSense 
D4.5 
Version 1.0 


+ localhost:8090/getApplicants?name=Blocktion Token&symbol-BT 


etApplicants?name=tok&symbol=BT 


name 


localhost:8090/updateBalance 


form-data x-www-form-urlencode ® raw binary 


ansaction 
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091/getBalance?name-tok&symbol-BT&msplID-Org1MSP&certlID-eDUwOTo6Q049VX. inMSSleGFtcGxILmNvbSxI 


name 


BmRmmBG 
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Test Case 
Result 


Achieved 


Table 31: E-AUCTION 02 unit test 


Test Case | E-AUCTION 02 Component E-auction module of 
ID energy trading 
framework 
Descripti | A priority table is managed by the related chaincode that keeps the total contribution 
on to the markets for each organization. This test, showcases the initialization of the 
priority table by the ESCO organization peer and how organizations are registered to 
the priority table after applying to a market. 
Req ID FR-UC4-02 Priority High 
Prepared | CERTH Tested by CERTH 
by 
Pre- e Each component of the e-auction has to be up and listening on their respective 
condition port, which includes at least an orderer, a peer for the ESCO organization, one 
(s) or more peers for prosumers and a couchdb for each peer. 
e The Priority Table and the Market chaincodes must be installed and 
instantiated on the e-auction channel of the blockchain network. 
e The application of each organization is running 
e Amarket has been initialized 


Test steps 


1 The ESCO organization’s peer initiates a new priority table using an HTTP POST request. 


2 ESCO peer retrieves the priority table with an HTTP GET request. The initial participants and 
market contribution lists should be empty. 


3 Peers of prosumer organizations (Org1 and Org2) apply to a market with an HTTP POST 
request including the ID of a market that they are applying for, the ID of the priority table 
and their role in the market (Org1 as Auctioneer and Org2 as Bidder) 


4 ESCO peer retrieves the priority table with a GET request. The organizations that have 
applied to a market should have been added to the lists of participants and contributions of 
the priority table and their initial contribution should equal to O. 


Input e Stepi 
HTTP POST request with empty request body 
e  Step2 


HTTP GET request without parameters 
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e  Step3 


"ID":"8680ccf55f5c4d03845ee82d4b1c35e5", 
"PriorityTable": "6687732881c54b60a0168aefd4c6cf60", 
"Role": "Auctioneer" 


"I|D":"8680ccf55f5c4d03845ee82d4b1c35e5", 
"PriorityTable": "6687732881c54b60a0168aefd4c6cf60", 
"Role": "Bidder" 


e Step4 


HTTP GET request without parameters 
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Result e Step1 


090/initPriorityTable 


Pretty 


ring=ddbd4432 581f: 7 c3aaf630caf0e15831d8; 


> localhost:8090/getPriorityTable 


localhost:80' PriorityTable 


4b60a0168aefd. , Participants”:null,"MarketContribution 
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localhost:8091 /applyToMarket 


none form-data 


4b 
4b 


= 


RA strina=3dea6fees45e617c7cfd09ce782502b91aa73a9e0f141b1879e3cBad732e93f1 
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localhost:8092/applyToMarket 


form-data x-www-form-urlencoded © raw binary 


Saefd4c6cf60", 


Pretty A => 


Transaction ID: 
X! (EXTRA string-264d3fd8b00c32cfb4eBb5df2a5f2a3b9811a6416a908f 78eaadb6f 7469db1d4 


Test Case | Achieved 


Result 
Test Case E-AUCTION 03 Component E-auction module of 
ID energy trading 


framework 


Descriptio | Every 15 minutes, a new market is initialized. The organizations have a specific time 
n slot (1 minute) to apply for that market and declare their roles. After the deadline 
passes then only the registered organizations will take part in the market. This test 
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showcases the initialization of a market by the ESCO organization and 
successful/unsuccessfull applications from prosumers’ peers. 

Req ID FR-UC4-02 Priority High 

Prepared CERTH Tested by CERTH 

by 

Pre- e Each component of the e-auction has to be up and listening on their 

condition( respective port, which includes at least an orderer, a peer for the ESCO 

s) organization, one or more peers for prosumers and a couchdb for each peer. 

e The Market chaincode must be installed and instantiated on the e-auction 
channel of the blockchain network. 

e The application of each organization is running 

e The priority table has been initialized and the ID is known to the organizations 

Test steps 

1 The ESCO organization's peer initiates a new market, with an HTTP POST request with 
empty request body. 

2 Peer of prosumer Org1 applies to the market with an HTTP POST request including the ID of 
a market, the ID of the priority table and 'Auctioneer' role, successfully. 

3 Peer of prosumer Org2 applies to the market with an HTTP POST request including the ID of 
a market, the ID of the priority table and 'Bidder' role, successfully. 

4 Peer of prosumer Org3 applies to the market with an HTTP POST request including the ID of 
a market, the ID of the priority table and 'Bidder' role, unsuccessfully because the 
application deadline has already passed. 

5 The ESCO organization's peer retrieves the markets list with an HTTP GET request. The 
market now includes Org1 and Org2 in the participants list, Org1 in the auctioneers list and 
Org2 in the Bidders list. 

Input data e Step1 

HTTP POST request with empty request body 
e  Step2 
{ 
"ID":"8680ccf55f5c4d03845ee82d4b1c35e5", 
"PriorityTable": "6687732881c54b60a0168aefd4c6cf60", 
"Role": "Auctioneer" 
) 
e Step3 & Step 4 
{ 
"ID":"8680ccf55f5c4d03845ee82d4b1c35e5", 
"PriorityTable": "6687732881c54b60a0168aefd4c6cf60", 
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"Role": "Bidder" 
} 
e Step5 
HTTP GET request without parameters 
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Result e Step1 


localhost:8090/initMarket 


Body 


none form-data x-www-form-urlencoded raw binary 


Transaction 
XI(EXTRA string-fa98f782ed48160f40d2303ce167a4424530240cfbc1f9b96016ef2f15e60579 
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localhost:8091 /applyToMarket 


binary 


Pretty 


Transaction ID: 
LH (EXTRA string=3dea6fee545e617c7cfd09ce782502b91aa73a9e0f141b1879e3c8ad732e93f1 
Y 


e Step3 
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localhost:8092/applyToMarket 


form-data x-www-form-urlencoded aw binary 


Pretty 


Transaction ID: 
%ICEXTRA string=264d3fd8b68c32cfb4e8b5df2a5f2a3b9811a6416a908f70eaadb6f7469db1d4 
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localhost:8093/applyToMarket 


Body 


form-data x-www-form-urlencoded raw binary 


Pretty 


Unable to invoke apply in market chaincode 


Org1MSP","C 
tLE89b3InMSS Le! 
tLEB9b3InM 
tLEB9b3JnM 
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Test Case 
Result 


Achieved 


Table 32: E-AUCTION_04 unit test 


Test Case | E-AUCTION_04 Component E-auction module of 
ID energy trading 
framework 
Descriptio | This unit test showcases an end-to-end VCG auction procedure with 2 winners. Org1 
n is the auctioneer and 2 bidders apply to the market, Org2 and Org3. 
Req ID FR-UC4-01, FR-UC4-02, FR-UC4- | Priority High 
07 
Prepared | CERTH Tested by CERTH 
by 
Pre- e Each component of the e-auction has to be up and listening on their respective 
condition( port, which includes at least an orderer, a peer for the ESCO organization, one 
s) or more peers for prosumers and a couchdb for each peer. 

e The Market, Priority Table, ERC20 and Vickrey Clarke-Groves chaincodes must 
be installed and instantiated on the e-auction channel of the blockchain 
network. 

e The application of each organization is running 

e The priority table has been initialized and the ID is known to the organizations. 

e Amarket has been initialized and the ID is know to the organizations. Org1 has 
applied as auctioneer, while Org2 and Org3 have applied as bidders. 

e Orgi, Org2 and Org3 have 500 tokens in their accounts. 

e  Org1, Org2 and Org3 have O initial market contribution. 

Test steps 

1 Org1 (auctioneer) peer initiates a new Vickrey Clarke-Groves auction, selling 40KWh of 
energy with reserve price 5 tokens/KWh 

2 Org1 peer queries blockchain to get the state of the auction with an HTTP GET request. The 
state should include the information of the Vickrey Clarke-Groves auction that Org1 
provided as initialization parameters and ‘State’ field should be equal to ‘Initialized’. 

3 Org2 (bidder) peer submits a bid of 100 tokens for 15KWh of energy. 

4 Org3 (bidder) peer submits a bid of 150 tokens for 20KWh of energy. 

5 Org1 peer queries blockchain to get the state of the auction with an HTTP GET request. The 
state should include the cryptographic commitments to the bids of Org2 and Org3 and 
'State' field should be equal to 'Bidding'. 
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Org1 peer queries the blockchain to retrieve the markets list with an HTTP GET request. The 
bidders list of the only existing market should be empty, as after each bidding the bidder is 
removed from the list of bidders. 


Org2 peer reveals its bid to the Vickrey Clarke-Groves chaincode with an HTTP POST 
request. 


Org3 peer reveals its bid to the Vickrey Clarke-Groves chaincode with an HTTP POST 
request. 


Org1 peer queries blockchain to get the state of the auction with an HTTP GET request. The 
state should include the revealed bids of Org2 and Org3 and ‘State’ field should be equal to 
‘Revealing’. 


10 


Org1 peer awards winners with an HTTP PORT request. At this step the chaincode calculates 
the e-auction results. 


11 


Org1 peer queries blockchain to get the state of the auction with an HTTP GET request. The 
state should include the results of the e-auction, including the winners, the amount of 
energy sold, the amount of energy that was not sold, the shares of energy between winners 
and the amounts of tokens that they should pay to the auctioneer. The ‘State’ field should 
be equal to ‘Awarding’. 


12 


13 


Org1 peer queries the blockchain to retrieve the markets list with an HTTP GET request. The 
auctioneers list of the only existing market should be empty, as after awarding the 
auctioneer is removed from the list of auctioneers. 


Org2 peer transfers the number of tokens that correspond to its bid to Org1’s account with 
an HTTP POST request. 


14 


Org3 peer transfers the number of tokens that correspond to its bid to Org1’s account with 
an HTTP POST request. 


15 


Org1 peer queries blockchain to get the state of the auction with an HTTP GET request. The 
‘State’ field should be equal to ‘Settling’. 


16 


Org1 peer retrieves its account balance through an HTTP GET request and should have 750 
tokens remaining, after receiving 100 tokens from Org2 and 150 tokens from Org3. 


17 


Org2 peer retrieves its account balance through an HTTP GET request and should have 400 
tokens remaining after transferring 100 tokens to Org1’s account. 


18 


Org3 peer retrieves its account balance through an HTTP GET request and should have 350 
tokens remaining after transferring 150 tokens to Org1. 


19 


Org1 peer retrieves the priority table through an HTTP GET request. Org1’s contribution 
should be 35KWh, Org2’s contribution should be equal to 15KWh and Org3’s contribution 
should be equal to 20KWh. 
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e Step1 
{ 
"MarketID":"e616a322ca7d460e9f44730e1161bfbf", 
"PriorityTablelD":"b7b61ed1d28346b1a7b8988e7b561caf", 
"Product" :{ 
"Name":"energy", 
"Units":"kwh", 
"Amount":40, 
"Status":"ForSale" 
b 
"ReservePrice":5 
} 
e Step 2 
auctionNum=5f57ce336f9a4962a3e2a32b5fff93e5 
e Step 3 
{ 
"AuctionNum":"5f57ce336f9a4962a3e2a32b5fff93e5", 
"Bid": 100, 
"Amount": 15 
} 
e Step 4 
{ 
"AuctionNum":"5f57ce336f9a4962a3e2a32b5fff93e5", 
"Bid": 150, 
"Amount": 20 
} 
e Step5 
auctionNum=5f57ce336f9a4962a3e2a32b5fff93e5 
e Step6 
HTTP GET request without parameters 
e Step 7 
{ 
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"AuctionNum": "5f57ce336f9a4962a3e2a32b5fff93e5", 
"Bid": 100, 
"Amount": 15 


e Step 8 


"AuctionNum": "5f57ce336f9a4962a3e2a32b5fff93e5", 
"Bid": 150, 
"Amount": 20 


e Step 9 
auctionNum=5f57ce336f9a4962a3e2a32b5fff93e5 


e Step 10 


{ 
"AuctionNum": "5f57ce336f9a4962a3e2a32b5fff93e5" 


e Step 11 
auctionNum=5f57ce336f9a4962a3e2a32b5fff93e5 


e Step12 
HTTP GET request without parameters 
e Step13 &Step 14 


{ 
"AuctionNum": "5f57ce336f9a4962a3e2a32b5fff93e5" 


e  Step15 


auctionNum=5f57ce336f9a4962a3e2a32b5fff93e5 


e Step16 


name=tok 
symbol=BT 
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msplD=Org1MSP 
certID=eDU...VVT 


e Step17 


name=tok 
symbol=BT 
mspID=Org2MSP 
certID=eDU...VVT 


e  Step18 


name=tok 
symbol=BT 
mspID=Org3MSP 
certID=eDU...VVT 


e Step19 


HTTP GET request without parameters 
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Result e Step1 


localhost:8091 /initVickreyCGAuction 


Body 


form-data x-www-form-urlencoded © raw binary 


91/getVickreyCGAuction?auctionNum=5f57ce 6233e2a32b5fff93e5 


Pretty 


t 
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localhost:8092/VCGsubmitSealedBid 


Body 


form-data x-www-form-urlencoded © raw binary 


2bsfff93esr, 


Body 


Pretty 


Transaction ID: 
%! (EXTRA string=519a955d6a23ab6496bfb018e76627892fa5f78de77a5881a4aa2a8a96b77c0e 


) 
J 


e Step 4 
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localhost:8093/VCGsubmitSealedBid 


Body 


none form-data x-www-form-urlencoded © raw binary 


Pretty => 


Transaction ID: 
XTRA string-acdc6c6ffddc2ecbe92062bcdcc0feab9d7828fee05095135cbcee9a265592a1 
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Pretty 


e Step7 
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localhost:8092/VCGreveal 


form-data x-www-form-urlencoded — '* raw binary 


ion ID: 
XTRA string=ab198c24df4a5078fc3a90dd3f5d5a4dc8398f06b9a8091d3a779dc33b35cfa4 
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localhost:8093/VCGreveal 


Body 


form-data x-www-form-urlencoded © raw binary 


Pretty zo 


Transaction ID: 
%!(EXTRA string=27cee7ibb8a02bfcb20279d20d9fSaaffb7199e012b7369043c8230a9d2826fd 
3 
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e Step 10 
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SDN-uSense 


none 


{ 


} 


localhost: 


form-data 


8091/VCGaward 


Body 


x-www-form-urlencoded 


® raw 


binary 
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Version 1.0 


© SDN microSENSE consortium 


Public document 


Page | 105 


SDN-uSense 
D4.5 
Version 1.0 


on?auctionNum- 
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localhost:8092/VCGsettle 


Body 


none form-data x-www-form-urlencoded  # raw binary 


Pretty =. 


Transaction I 


47bddeea0bfeB06b0eBaf 3f40e27bb1f4bd7779d1cda641b62900aa2666e2c8c 
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localhost:8093/VCGsettle 


Body 


form-data A orm-urlencoded — '* raw binary 


e  Step15 
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localhost V/getBalance?name-tok&symbol-BT&mspID-Org1MSP&certlD-eDUwOTo6Q049VXNIcjFAb3JnMSSIeGFtcGxILmNvbSxMPVNhbiBGcmFuY4 


Params 


mspiD 


SNS 


tiD 6QC 4 3 eGFtc «MPVNhbiBC 
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localhost:8092/getBalance?name-tok&symbol-BT&mspID-Org2MSP&certlD-eDUwOTo6Q049VXNIcjFAb3jnMiSleGFtcGxILmNvbSxMPVNhbiBGcmF: 


KEY 


name 


SNS 


Pretty 


/getBalance?name-tok&symbol-BT&mspID-Org3MSP&certlD-eDUwOTo6Q049VXNIcjFAb3J]nMySleGFtcGxILmNvbSxMPVNhbiBGcmFuY2 


KEY 


name 


VALUE DESCRIPTION 


Test Case | Achieved 
Result 
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Table 33: E-AUCTION_05 unit test 
Test Case | E-AUCTION 05 Component E-auction module of 
ID energy trading 
framework 


Descriptio | This unit test showcases the rejection of a bidder that bids to an auction after the 
n bidding deadline. 


Req ID FR-UC4-07 Priority Medium 

Prepared CERTH Tested by CERTH 

by 

Pre- e Each component of the e-auction has to be up and listening on their 
condition( respective port, which includes at least an orderer, a peer for the ESCO 
s) organization, one or more peers for prosumers and a couchdb for each peer. 


e The Market, Priority Table, ERC20 and Vickrey Clarke-Groves chaincodes must 
be installed and instantiated on the e-auction channel of the blockchain 
network. 

e The application of each organization is running 

e The priority table has been initialized and the ID is known to the organizations. 

e A market has been initialized and the ID is known to the organizations. Org1 
has applied as auctioneer, while Org2 and Org3 have applied as bidders. 


Test steps 


1 Org1 (auctioneer) peer initiates a new Vickrey Clarke-Groves auction, selling 40KWh of 
energy with reserve price 5 tokens/KWh 


2 Org2 (bidder) peer submits a bid of 100 tokens for 15KWh of energy. 


3 Org3 (bidder) peer submits a bid of 150 tokens for 20KWh of energy but the bid is overdue. 


4 Org1 peer queries the blockchain to retrieve the markets list with an HTTP GET request. The 
bidders list of the only existing market should include Org3, since Org3's peer bid got 
rejected and it should have the opportunity to take part in a subsequent auction of the 


market. 
Input data e Step1 
{ 
"MarketID":"", 
"PriorityTablelD":"", 
"Product":{ 
"Name":"energy", 
"Units":"kwh", 
"Amount":40, 
"Status":"ForSale" 
} 
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"ReservePrice":5 


e Step 2 


"AuctionNum":"", 
"Bid": 100, 
"Amount": 15 


e Step 3 


"AuctionNum":"", 
"Bid": 150, 
"Amount": 20 


e Step 4 


HTTP GET request without parameters 


e Step1 
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localhost:8091 /initVickreyCGAuction 


form-data x-www-form ode raw binary 


Transaction 


%! (EXTRA string-3387d3d949126363b19b4ec6bfd57febba35622340491ec448b0640969ad2b1e 


e Step2 
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localhost:8092/VCGsubmitSealedBid 


Body 


— 
none form-data x-www-form-urlencoded © raw binary 


{ 


Body 


Pretty =D 


Transaction ID: 
%! (EXTRA string=d6166687a0b403f3a8f73b49bf67fc15af366a065df02404ab0c79e43637d03a 


" 
7 
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localhost:8093/VCGsubmitSealedBid 


Body 


none form-data x-www-form-urlencoded © raw binary 


{ 


d3ad2a4/, 


Pretty 


Unable to invoke submit in VickreyCGAuction chaincode 


DESCRIPTION 


Test Case Achieved 
Result 
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5.2 Blockch 


ain Based Intrusion and Anomaly Detection module unit tests 


Table 34: BIAD_01 unit test 


condition(s) 


Test Case BIAD 01 Component BIAD network and 

ID chaincode 

Description | The device is registered in the blockchain to be identified for futures 
interactions. 

Req ID FR-GR-06; FR-UC4-05 Priority High 

Prepared TECNALIA Tested by TECNALIA 

by 

Pre- e Each component of the BIAD has to be up and listening on their respective 


port, which includes at least an orderer (7050), a peer (7051), the CA 
(7054), couchdb (5084) and REST API (4040). 

e The chaincode must be installed and instantiated on the blockchain 
network. 

e The device must have a way to sign a transaction. In this case it is done via 
Rest API, so it must be log in. 


Test steps 


1 The device sends a POST HTTP request to the API, using RegisterDevice method, with its 
IP as identifier in the body and the authentication token in header. 


2 The orderer receives and mined the transaction in the next block, so that it can be added 
to the chain. 


3 Check if the device has been correctly registered using GetDevicelnfo route at the API. 


Input data 


{“dvclD”:”10.10.10.100”} 


Result 


e Step1 
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POST + / / /invoke/registerDevice Send 


:"10.10.10.100" 


EJ 2: ss -— 


Preview + l Cookie Timeline 


"invoke", 
"opi 
"ccsdn", 
"registerDevice", 


"73677669b04fa4348a59cb3fd4802602a487421626d6f03edc2b3fdec1a33e3f", 


{ 
"10.10.10.100", 


true 
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POST + ERES ERES / EEE auery/getDevicelnfo Send 


200 OK 267 ms 128B Just Now v 


Preview + 


{ 


Test Case Achieved 


Result 

Table 35: BIAD 02 unit test 
Test Case BIAD 02 Component BIAD network and 
ID chaincode 


Description | The device registers a hash and a processing parameter to be monitored with 
some initial values. If they already exist, the value is updated, and its validity is 
checked (same than BIAD 03 and BIAD 04 functionalities). 


Req ID FR-UR-06; FR-GR-06; FR- Priority High 
UC4-05 
Prepared TECNALIA Tested by TECNALIA 
by 
Pre- e Each component of the BIAD has to be up and listening on their respective 
condition(s) port, which includes at least an orderer (7050), a peer (7051), the CA 


(7054), couchdb (5084) and REST API (4040). 
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e The chaincode must be installed and instantiated on the blockchain 
network. 

e The device must have a way to sign a transaction. In this case it is done via 
Rest API, so it must be log in. 

e The associated device must be previously registered on the blockchain 
and have a devID identifier. 


Test steps 


1 The device sends a POST HTTP request to the API, using RegisterHash or RegisterRecord 
methods, with their respective initial values in the body in JSON format. 


2 The orderer receives and mined the transaction in the next block, so that it can be added 
to the chain. 

3 Check if the Hash/Record has been correctly registered using GetDevicelnfo route at the 
API. 


Input data RegisterHash: 
{“dvclD”: “10.10.10.100”, 
“path”: “/etc/passwd”, 


“value”: “fn3y09bty340c0rf354tv4635 bv37c3f04n5v2v52040cweoi”} 


RegisterRecord: 
{“dvclD”: “10.10.10.100”, 


“param”: "USED MEM", 


“value”: 5, 
"max": 60, 
"min": 2) 
Result e Step1 
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POST + ees / Eis ERR /invoke/registerHash Send 
200 OK 2.365 317 B Just Now v 
Preview v 
{ 
© SDN microSENSE consortium Page | 120 


Public document 


|44-/ SDN-uSense 
ka D4.5 
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POST + / / /query/getDevicelnfo Send 


Header 


:"10,10.10.160" 


ELA ue cs nus 


Preview ¥ 


"query", 
"ehis 
"ccsdn", 
"getDeviceInfo", 
: © 
"10.168.18.100", 


[ 


"1kryIbFfcxraifnJxt8413kdGKJ", 
"10.10.10.100", 
"/etc/passwd", 
"fn3yO9bty340cOrf354tv4635bv37c3f04n5v2v52040cweoi" 
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Test Case Achieved 
Result 


Table 36: BIAD_03 unit test 


Test Case BIAD_03 Component BIAD network and 
ID chaincode 


Description | The device updates the hash and the parameter registered on the blockchain, so 
it can be processed. This time there will not be any anomaly performance. This 
case is possible to do with RegisterHash function when the hash already exists 
on the ledger. 


Req ID FR-UR-06;FR-GR-06; FR- Priority High 
UC4-05 
Prepared TECNALIA Tested by TECNALIA 
by 
Pre- e Each component of the BIAD has to be up and listening on their respective 
condition(s) port, which includes at least an orderer (7050), a peer (7051), the CA 


(7054), couchdb (5084) and REST API (4040). 

e The chaincode must be installed and instantiated on the blockchain 
network. 

e The device must have a way to sign a transaction. In this case it is done via 
Rest API, so it must be log in. 

e The associated device must be previously registered on the blockchain 
and have a devID identifier. And in case of processing parameter, it must 
be previously registered as well. 


Test steps 


1 The device sends a POST HTTP request to the API, using UpdateHash or UpdateRecord 
methods, with their respective identity and actual values in the body, in JSON format. 


2 The orderer receives and mined the transaction in the next block, so that it can be added 
to the chain. 


3 Check if the Hash/Record has been correctly updated and if there is any alert, using 
GetDevicelnfo route at the API. 


Input data UpdateHash: 
{"hashID":"1krylbFfcxraifnJxt8413kdGKJ", 


"value":" fn3y09bty340c0rf354tv4635bv37c3f04n5v2v5204ocweoi"} 
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UpdateRecord: 
{"recordID":"1krylbFfcxraifnJxt8413kdGKJ", 


"value": 6} 


Result e Step1 


Post - ERES EEE EE invoke/updatetiah 


200 OK 2.25 271B Just Now v 


Preview + 


{ 


e Step2 
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POST + / / /query/getDevicelnfo Send 


:"10.10.10.100" 


Beautify JSON 


| 2000K | 270 ms 284 B Just Now v 


Preview ¥ Cookie Timeline 


"getDeviceInfo", 


{ 
"10.10.10.100", 


[ 


"1kryIbFfcxraifnJxt84ISkdGKJ", 
"10.10.10.160", 
"/etc/passwd", 
"fn3yO9bty340cOrf354tv4635bv37c3f04n5v2v52040cweoi" 
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Test Case Achieved 
Result 


Table 37: BIAD 04 unit test 


Test Case BIAD_04 Component BIAD network and 
ID chaincode 


Description | The device updates the hash and the parameter registered on the blockchain, so 
it can be processed. This time we will introduces an anomaly performance. 


Req ID FR-UR-06;FR-GR-06; FR- Priority High 
UC4-05 
Prepared TECNALIA Tested by TECNALIA 
by 
Pre- e Each component of the BIAD has to be up and listening on their respective 
condition(s) port, which includes at least an orderer (7050), a peer (7051), the CA 


(7054), couchdb (5084) and REST API (4040). 

e The chaincode must be installed and instantiated on the blockchain 
network. 

e The device must have a way to sign a transaction. In this case it is done via 
Rest API, so it must be log in. 

e The associated device must be previously registered on the blockchain 
and have a devID identifier. And in case of processing parameter, it must 
be previously registered as well. 


Test steps 


1 The device sends a POST HTTP request to the API, using UpdateHash or UpdateParam 
methods, with their respective identity and actual values in the body, in JSON format. 


2 The orderer receives and mined the transaction in the next block, so that it can be added 
to the chain. 
3 Check if the Hash/Parameter has been correctly updated and if there is any alert, using 


GetDevicelnfo route at the API. 


Input data UpdateHash: 
{"hashID":"1krylbFfcxraifnJxt8413kdGKJ", 


"value":"attack_to_10.10.10.100"} 


UpdateParam: 


© SDN microSENSE consortium Page | 125 
Public document 


(x) SDN-uSense 


D4.5 
Version 1.0 


Result 


{"record|D":"1krylbFfcxraifnJxt8413kdGKJ", 


"value": 80} “dvcID”:”10.10.10.100”) 


e Step1 


POST + / 38 / 


à /invoke/updateHash 


:"1kryIbFfcxraifnJxt8413kdGKJ", 
:"attack to 10.10.10.100" 


200 OK 2.36 s 399 B 


Preview + 


"invoke", 
"chi". 
"ccsdn", 

"updateHash", 


"5c588d29bbd4e65135337f0dd043e91fc884b0c980fa66947642d060a06f4bf5", 


ja 
"4ksO4kNTuVzZIFh81lq 
"10.10.10.100", 
"1kryIbFfcxraifnJxt 
"Corrupted hash", 


"fn3y09bty340c0rf354tv4635bv37c3f 
"attack to 10.10. 
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uRqoRzzmih", 


84ISkdGKJ", 


04n5v2v52040cweoi”", 
10.100" 


Send 


Just Now + 
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POST + / / /query/getDevicelnfo Send 
:"10.10.10. 1600" 
200 OK 241 ms 497 B Just Now v 
Preview v 
t 
"query", 
tohii 
"ccsdn", 
"getDeviceInfo", 
{ 
"10.10.10.100", 
[ 
"1kryIbFfcxraifnJxt8413kdGKJ", 
"10.10.10.100", 
"/etc/passwd", 
"attack to 10.10.10.100" 
"1ks04kNTuVzIFh8lquRgoRzzmih", 
"10.10.10.160", 
"1kryIbFfcxraifnJxt8413kdGKJ", 
"Corrupted hash", 
"fn3yO9bty340cOrf354tv4635bv37c3f04n5v2v52040cweoi", 
"attack to 10.10.10.100" 
} 
Test Case Achieved 
Result 
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Table 38: Lib_mon_001 unit test 


Lib mon 001 BIAD Agent 


Testing of the Monitoring Lib 


FR-GR-06; FR-UC4-05 


TECNALIA TECNALIA 


e Source code of the monitor lib 
e No built code 


cd lib/monitor_lib 


make test 


cd test && ./test 


prt0875a@PRTO875A: ~/Proyectos/SDNmicrosense/agent-sdn/lib/monitor_lib/test 


Archivo Editar Ver Buscar Terminal Ayuda 


Achieved 


Table 39: Lib_hash_001 unit test 


Lib hash 001 BIAD Agent 


Testing of the Hashing Lib 


FR-GR-06; FR-UC4-05 


TECNALIA TECNALIA 


e Source code of the hashlib 
e No built code 
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1 cd lib/hashlib 

2 make test 

3 cd test && ./test 

Input 

data 

Result prt0875a@PRTOB75A: ~/Proyectos/SDNmicrosense/agent-sdn/lib/hashlib/test 


Test Case | Achieved 


Archivo Editar Ver Buscar Terminal Ayuda 


Result 
Table 40: Fabric conn 001 unit test 
Test Case Fabric conn 001 Component BIAD Agent 
ID 
Description | Testing of the Fabric connection Lib 
Req ID FR-GR-06; FR-UC4-05 Priority -- 
Prepared TECNALIA Tested by TECNALIA 
by 
Pre- e Source code of the fabric_conn 
condition(s) e No built code 
Test steps 
1 cd lib/fabric_conn 
2 make test 
3 cd test && ./test 
Input data 
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Result Terminal does not show any error. 
Test Case Achieved 
Result 
Table 41: agent 001 unit test 
Test Case agent_001 Component BIAD Agent 
ID 
Description | Testing of the agent. 
Req ID FR-GR-06; FR-UC4-05 Priority -- 
Prepared TECNALIA Tested by TECNALIA 
by 
Pre- e Source code of the agent 
condition(s) e No built code 
Test steps 
1 cd agent 
2 make agent 
3 ./agent (with root permissions) 
Input data 
Result Terminal does not show any error. 
Test Case Achieved 
Result 


6. System Installation 


6.1 E-auction module 


6.1.1 


E-auction module installation 


To deploy the e-auction module, first of all it is necessary to have an operative Hyperledger Fabric 
blockchain network and create a channel with the participants. For the proof of concept, we have 
launched a network using Docker containers, that is based on the basic network that Hyperledger 
Fabric provides. We have added 3 more organizations to simulate a network with 3 prosumers and 1 


ESCO company, because the basic network includes only 1 organization and 1 peer node. 


Requirements for the Hyperledger Fabric blockchain network and API: 
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e Docker 
e Go language 


Commands for starting the network and the applications for each organization: 


cd basic-network from root project folder 
./start.sh and wait until Fabric network is setup 
cd OrgXApp from root folder 

./blocktion 

cd TokenBankApp from root folder 

./blocktion 


ou Bo Ne 


6.2 Blockchain Based Intrusion and Anomaly Detection module 


6.2.1 BIAD installation 
To deploy the BIAD, first of all it is necessary to have an operative Hyperledger Fabric blockchain 
network and create a channel with the participants. For the proof of concept, we have launched a 
network using Docker containers. 


Requirements for the Hyperledger Fabric blockchain network and API: 


e npm 
e docker 
e nvm v8.17.0 


Commands for deployment the Hyperledger Fabric blockchain network and API: 


e yarn generate 
e yarn rest:start 
e yarn explorer:start 


Then, we install and instantiate the chaincode, named ccsdn for the example, on the created channel. 
Requirements for chaincode component: 


e fabric-tecnalia-cli 
e network-profile 


Commands for the deployment of chaincode component: 


e install -f ./network/cc.network-profile.yaml --channel ch1 -c [chaincodeName] -g ./ -p 
[chaincoidePath] -t golang -V 
e instantiate -f ./network/cc.network-profile.yaml --channel ch1 -c [chaincodeName] -V 


Finally, we need to deploy the agent on the client (see section 6.2.2) and create a certificate on the CA, 
which will be used to sign the transactions. The client will send input data to the REST API server, where 
the transaction will be generated and sent to the blockchain corresponding node. 
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6.2.2 Agent installation 
Before any installation of the agent can take place, some prerequisites must be met (in the Project 
Raspberry PI simulating the devices are used to install the agent). To do so, the script 
install_prerequisites.sh must be run. Once the prerequisites are installed it is time to install the agent. 


The code provided contains a Makefile, which compiles all the software by writing make all. When 
doing make all, the next parts are compiled: 


e Hash lib: Library which hashes files 

e Monitor lib: Library which gets information about RAM, processes and uptime 
e Fabric lib: Library which connects with the Blockchain module 

e  Processhider lib: Library which implements the process hider utility. 

e Agent: executable of the BIAD agent 


Before doing any make all command, it is required to configure the endpoint with the Blockchain, the 
files to be hashed and the ID of the device sending information. This is directly made in the agent.c file, 
by changing the variables. Here we have an example of a possible configuration, with the information 
to be modified in red color: 


fdefine num files 2 
char deviceID[20]="1111"; 
char blockchain node[20]-2"172.26.41.127"; 


char files[num files][length files]- 
( 

"/etc/passwd", 

"/var/log/auth.log" 
}; 
Once this information has been updated, the make all command will install the whole software. Also, 
for testing purposes, a test/ folder is created within every library folder with code testing the 
functionality when make all is launched. This allows to test every single part of the agent before being 


integrated into the final platform. 


7. Innovation Summary 


As part of task T4.5, a complete and secure-by-design Blockchain-based Energy Trading Framework has 
been designed and developed as a part of the SDN-microSENSE project. The Blockchain-based Energy 
Trading Framework leverages the other modules of SDN-microSENSE to provide functionalities that 
enhance the robustness and efficiency of the grid. Specifically, any potential trades that have been 
calculated by the energy trading framework are further checked by the OTSC tool in terms of feasibility 
and with regards to the balance of the system, before they are actually applied to the grid. 
Furthermore, an integrated, distributed IDS (BIAD) have been developed to work complementary to 
the market that checks the validity of the participant's devices. BIAD communicates with XL-EDPS and 
S-RAF providing another layer of security to the system and ensures that the participants are trusted 
and pose no risk to the overall operation of the electrical network. To our knowledge this complete 
approach regarding energy blockchain market have not been implemented in such a wide manner, 
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encompassing trading, security, privacy and performance at the same time with regards to the whole 
system. 


One of the innovations is the use of the Hyperledger DLT open source project, in this case, Hyperledger 
Fabric. Hyperledger Fabric is better suited for the EPES domains in terms of performance [3] and data 
privacy in contrast to other initiatives which are based on other blockchain platforms. By relying on a 
permissioned architecture, security and privacy of the e-auction transactions are ensured towards the 
peers in the network in contrast to public blockchain technologies. On that aspect, the e-auction 
module is based on the use of smart contracts, providing an automated and decentralized way of 
resolving auctions and uses a Vickrey-Clark-Groves (VCG) auction model. VCG is a sealed-bid type of 
auction that ensures maximization of utility, as there could be multiple winners and the system would 
assign the sold energy to buyers in a socially optimal manner [4]. At the same time, VCG pushes the 
buyers to bid near their true estimated value. Additionally, incentives are provided to drive participants 
to participate in a regular manner in order to climb the priority table. Penalties ensure that participants 
will deliver the agreed amount of energy and will pay their debts, as non-compliance of these two 
factors would lead to a fall in the priority table. Finally, a bank mechanism protects any participants 
that is owed tokens. 


The second main innovation is the integration of security monitoring and reporting procedures in the 
energy trading framework by the BIAD module. The BIAD module is a distributed system comprising of 
lightweight agents, which are installed on the devices of the participants (i.e. RPI based smart meter, 
IEDs, RTUs). The agent calculates a hash from critical files of the system at regular intervals and uses 
the blockchain DLT to ensure the uncompromised status of the devices by checking for any difference 
with the previously reported hash. In case of any anomaly, the owner of the device cannot participate 
in any auctions; either as seller or as bidder and XL-EDPS is informed for further actions. One of the 
main advantages of the BIAD agents is that they are lightweight and are written in C, which enables 
support to any hardware in the market, while at the same time ensuring high-performance. The 
installation and any configuration of the agent is made locally, as such no information is disseminated 
outside of the device, other than the hash, further preserving the privacy of the device. Additionally, 
the agent can be equipped with process-hiding mechanisms in order to inhibit any attacker from 
discovering and tampering with the agent itself. Overall, BIAD is an innovative IDS, leveraging the 
distributed blockchain architecture to provide an easy indication of trust among participating devices 
and operating as another layer of defense against cyber-attacks. 
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8. Conclusions 

In conclusion, this deliverable describes the final outcome of Task T4.5, Energy Exchange using 
Blockchain Technologies, which is included in WP4. Some minor updates are possible by the end of the 
project, in the context of the continuous improvement of the complete developed system. These 
updates will be mainly related to the algorithms run by the software agents participating in the Energy 
Trading Framework, and the further expansion of the Framework’s functionalities. 


The Energy Trading Framework has been implemented and its functionalities, inputs/outputs and 
interconnections with other SDN-microSENSE components and modules have been analytically 
described, along with a presentation of all the related work in the literature. Taking under 
consideration the project’s requirements (D2.2) and its architecture (D2.3), the system was developed 
using the Hyperledger Fabric framework. The system offers a safe and privacy preserving environment, 
in which energy transactions can be performed between prosumers of an islanded part of the main 
grid. Thus, the island can be sustainable and fully operational until it is ready to reconnect to the main 
grid. Moreover, the cryptographic mechanisms which were deployed ensure the participants’ sensitive 
data privacy, and the algorithms run by their corresponding software agents, ensure their economic 
sustainability. 


This deliverable produces the fourth layer of the SDN-SELF component, which aims to improve the 
robustness of the grid against cyberattacks. The blockchain-based Energy Trading Framework offers 
increased resilience against cyber threats, taking into account the real time security status of the 
network. The continuous monitoring of the grid’s infrastructure and the filtering of all the proposed 
transactions to verify their feasibility, provides secure energy trading transactions between microgrids 
that do not jeopardize the grid’s stability. 


The adoption of an ERC20 token mechanism for financial transactions of trading parties, overcomes 
the computation overload that is imposed by cryptocurrency such as Bitcoin or Ether and makes 
transactions faster and more efficient. Also, the utilization of a private permissioned network that 
Hyperledger Fabric provides, enhances transaction privacy trough dedicated channels for energy 
trading between organizations and fosters an ecosystem of trusted parties that have competitive 
interests but common goals. Finally, the selection of Vickrey Clarke-Groves auction mechanism, keeps 
the benefits of simple Vickrey auction mechanism that other studies suggest, such as sealed bids that 
ensure the true valuation of the product and adds extra value by sharing the offered amount of energy 
to multiple winners according to their needs, maximizing the value of the product at the same time. 


The system presented in this document refers to islands not connected to the main distribution grid. 
These islands consist of prosumers, which have the ability to produce and store energy, apart from 
consuming it. The OTSC tool ensures the energy sustainability of the islands upon their initial creation. 
A possible improvement of the Energy Trading Framework is the addition of the functionality of trading 
energy with the main grid. In this case, consumers without the ability to produce or store energy can 
be included to the energy market by participating in energy auctions as bidders. Also, incentives will 
be given to the consumers, for example, for having lower consumption at peak hours of the day. All 
the stakeholders will receive the prices offered by the main grid for buying and selling energy, and they 
will compare these prices with the corresponding prices offered by the rest of the stakeholders. This 
way, they will have the ability to choose the market which ensures them the maximum profit and at 


© SDN microSENSE consortium Page | 135 
Public document 


(x) SDN-uSense 
D4.5 


Version 1.0 


the same time, the local, blockchain-based energy market will operate in alignment with the main 
grid’s market. 


The evaluation of the Energy Trading Framework during the implementation of the SDN-microSENSE 
pilot demonstrations will lead to further development and research regarding this component, and the 
possible improvement of its functionalities will be investigated. Another possible extension that may 
be explored, is the implementation of a web interface that provides suggestions to end users for 
participation to the market, instead of the current fully automated procedures that are processed by 
software agents. 
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